Create a Enum RPC message

[ni]

Create a Enum RPC message

[a-clucker]

This ticket would greatly aid us in being able to use proto for lower-level data, e.g. bit fields. This is a key item keeping us from more fully adopting proto/grpc-labview as an IDL for interfaces between LabVIEW and other supported languages (py, C++, etc). This came up on the volta project (private repo in NI org), but we've encountered other examples of wanting this use case.

Also, minor note of value from Chris in 20, rings vs enums:

We should create proper rings for them in LabVIEW. Enums can be sparse and have repeated values so we will have to create rings to support all possible enums.

Edit: FYI to @eyesonvis

[drjdpowell]

I think you should allow the user to choose either a ring or an enum. Although an enum is not always possible, it is much better than a ring.

[eyesonvis]

Neither rings nor enums will fulfill all the desired use cases, so we're going to need to decide which benefits are more important.

Rings allow sparse values and localization.

Enums provide better diagram readability (e.g., on Case Structure frames). As type definitions, they will update all instances when the item list changes.

Neither rings nor enums will allow multiple names for the same numeric value.

In my opinion, enums are supposed to be logically independent of their numeric backing value, and so users should have a function that does a look up when they need to get a number for an enum value. Similarly, users can have a corresponding ring for places where localization is required, and a function that looks up the corresponding enum value so that the rings are only UI/API elements, and their numeric value is never used in code.

[Rohith-Grandhi]

Listing down some of Enum features as defined in Proto3 and if they can be supported with LabVIEW Ring or Enum

Enum features as defined in proto 3	LabVIEW Ring	LabVIEW Enum
must contain a constant that maps to Zero as its value	Yes	Yes
use enum type declared in one message as the type of a field in a different message	Yes	Yes
Enum value must be in the range of 32-bit integer	Yes	No
Non sequential values	No (can workaround?)	No (can workaround?)
Aliases - Same value to different enum constants	No	No
Reserved Values - The proto buff compiler will complain if any future users try to use the identifiers specified as Reserved	No	No

[eyesonvis]

We're planning to implement this feature using LabVIEW Enums. This means that users will have to call a look-up function to get the numeric value for an enum item.

[drjdpowell]

This means that users will have to call a look-up function get the numeric value for an enum item.

Sorry, what does this mean? LabVIEW Enums are already numbers, so what is this look-up?

[eyesonvis]

The proto buf might say:
A=0;
B=0;
C=1;
D=20;

But the LabVIEW enum will be 0, 1, 2, 3. We'll provide a VI that takes the (typedef) enum type and returns the Int32 value.

[drjdpowell]

Ah, so it would only be if teh User actually needed the numeric value that they would need to use this look up.

[Rohith-Grandhi]

Support for Enum type is now present in Version 1.0.0.2 release