Support passing in int for enum parameters in MethodDescriptor.

[stevevex]

Currently an Enum parameter received as int will fall into the else branch and be processed by custom converters, but an int is not directly convertible into a JsonObject and will fail the parameters.getJsonObject call below.

[xpconanfan]

Does this assume Enum will always evaluate to int? Doesn't seem like a safe assumption

[stevevex]

Does this assume Enum will always evaluate to int?

Yes. If the Python method of a snippet RPC is called with an Enum param, Python will send it as int in the RPC request. Agreed that the assumption is not perfectly safe but I think it's an improvement from the current state. Right now I can't have my Java RPC functions accept Enum parameters like below.

# Java
@Rpc
public void eat(Fruit fruit) {} # enum Fruit { APPLE, ORANGE, PEAR }

# Python
self.dut.my_snippet.eat(Fruit.APPLE) # Fruit is either kept in sync in both languages or e.g. defined in ProtoBuf.

It seems that my only options are to either use a custom SnippetObjectConverter & a JSON wrapper, or to accept an int param and do Enum.forNumber on the Java side.

I believe this change itself is safe because it will support a new usage that is not possible to exist before.

[ko1in1u]

How about changing the Enum class in Python to IntEnum class? Then its value will be considered as a integer when used, so in the snippet side, just need to get a int type.

@Rpc
public void eat(int fruit) {} 

@enum.unique
class Fruit(enum.IntEnum):
  APPLE = 1
  ORANGE = 2
  PEAR = 3

self.dut.my_snippet.eat(Fruit.APPLE)

[stevevex]

Then its value will be considered as a integer when used, so in the snippet side, just need to get a int type.

Thank you! Yes that would work. This change is only proposed to allow users to directly use the Enum type on the snippet side. In cases where the Enum is kept well in sync with an ifttt-lint or is defined cross-language as a ProtoBuf Enum, it would help users keep the Enum consistent.

I think there are 2 ways to address the unsafe assumption here

1. I can make a type check on the incoming JSONArray, so that we only enter the Enum-casting branch if parameters.optInt(index, -1) != -1
2. We can make a rule that if a user expects the Mobly snippet lib to handle Enum for them, they must use the ordinal of the enum. (which is sort of guaranteed by Python if using an IntEnum or a ProtoBuf Enum)

Reviewers please let me know which one you prefer.