Extensible enums

[candidus]

I'm thinking about extending enums in a type safe manner:

The enum is stored as a variant member in a class, EnumBase.lvclass .
EnumBase.lvclass provides three methods:
public GetValue()
protected SetValue()
public GetEnumTypeName()

A concrete enum class is derived from EnumBase.lvclass and must provide getters and setters for the enum type.
We can extended such an enum class by inheritance.

Getting the right enum value requires two steps:
First we have to use decide which getter must be used, depending on the return value of GetEnumTypeName() .

Unfortunately we must use strings here. Then we can call the appropriate getter.

Any comments appreciated!
 

ExtensibleEnum.zip

[mje]

Haven't looked at your code because I'm on mobile but the beauty of enumerated types in any language are how under the hood they're just numbers. Attach names at design time for convenience, but in the end still numeric when operating. I don't see how you can get this benefit with objects?

[ShaunR]

Haven't looked at your code because I'm on mobile but the beauty of enumerated types in any language are how under the hood they're just numbers. Attach names at design time for convenience, but in the end still numeric when operating. I don't see how you can get this benefit with objects?

 

I agree. The only purpose of an enum is to code improve readability. Granted LV takes it one step further by linking to case statements. But again. The benefit is readability.If you want a run-time extensible numeric type, use a ring.

[hooovahh]

If you want a run-time extensible numeric type, use a ring.

Yup that was what I was thinking.  Possibly a ring with the string values in a look up table or something so you don't need to read the string values with a property node every time you want to know which item was selected.

 

Although that gets me thinking.  So with an Enum we can read what all the possible values are using the OpenG Get Strings from Enum function.  Is it not possible to read the string values of a ring control the same way because that information is not contained in the wire, only the numeric representation is?

[candidus]

I don't want to extend enums at runtime but at compile time.
Here is my use case:

I have a class DeviceContainer.lvclass that manages objects of type Device.lvclass in a map.
DeviceContainer.lvclass has a dynamic dispatch method GetDeviceByID() .
It takes a parameter of type enum DeviceIDEnum.ctl and returns a device object.
I chose enums over rings because the name strings are part of the typedef and the case structure handles them nicely.
So to speak, I use an enum as a collection of string constants.

DeviceContainer.lvclass has child classes. Every child class supports a different set of devices but at least
the one defined by the base class. That means I have to override GetDeviceByID() to support another enum type
and now things get complicated: I don't want to modify DeviceIDEnum.ctl of the base class.
My current workaround is to pass the enum as a variant and define the appropriate enum for every child class.

Enum classes could help here: First, the ID parameter of GetDeviceByID() is of type DeviceIDEnum.lvlass .
The parameter is type safe and extensible now, I can pass any child class of DeviceIDEnum.lvlass .
Second, no mdification of the original DeviceIDEnum.lvlass is required. I can inherit from it.

OK, while I'm writing this I get the strange feeling that I'm thinking way too complicted...

[PaulL]

If I understand correctly, then DeviceContainer.GetDeviceByID() functions as a factory method.  (My preferred implementation of such a thing is via the Factory Method Pattern.)

We also use an Enum (strict typedef, actually) as the input to our factory method, which input specifies the class to return.  As you say this makes the method specific for the component. We have analyzed the trade-off and, to this point, we have decided to keep the benefits of the Enum on the one hand, and make a specific instance of the Factory Method Pattern for each component on the other hand. (This isn't a problem for us, although I do wonder if we might realize an advantage if we could figure out how to generalize this.  I don't think there is a way, though, because that's how Enums work--and that's actually why we use them, after all.)