Add sparse enums to LabVIEW

[tst]

Today, the enum data type in LabVIEW only allows having sequential numeric values (0, 1, 2, 3, etc.).

It would be very useful to have sparse enums, meaning enums which can have custom numeric values assigned to their strings, just like you can do today with rings.

If you want an example where this will be useful, think of error codes - this would allow you to use an enum on the diagram to select the error, or in a case structure.

[wiebe@CARYA]

>The mechanism of "NI prioritizes features based on 'Kudos'" is broken and it does not suit the needs of professional labview developers.  

That's not the mechanism, and it doesn't say anywhere that it is. Kudos are just one of the factors.

[AristosQueue (NI)]

@tyale Kudos is one of the mechanisms for pushing a feature, but it is not the only one. High kudos does not guarantee action; it only encourages action. Our direct interviews with customers and review of user code are more influential on choosing the features we implement.

Sparse enums get evaluated every couple years because of the high kudos they have here. The development time for sparse enums is judged to be quite high* and the customer base that would use them appears to be fairly narrow**, and so they have never won out against other development priorities. The idea remains open for future evaluation.

* Making sparse enums work is more than just creating a type with a list of name/value pairs. Math operations have to be either excluded or taught to handle the types correctly. Coercion rules have to be decided upon. There's a long tail on the feature of small stuff that either has to be implemented or blocked, and even blocking takes time. Even more expensive is the flag set, which is a particular form of sparse enum where logical operations are allowed but not general math, but flag set is the use case I personally see most commonly for a sparse enum.

** Roughly 10% of LV users create refnums. We expect that the user base for sparse enums would be smaller.

[Carlnath]

Although I absolutely agree this is actually easily implemented Using an enum, and a case structure.

Feed your enum into a case structure, then have that case pass the desired enum value out of the case structure.

I absolutely agree that allowing Sparse Enums would be better, as it would clean up the block diagram.

This is from a personal project I'm working on to programatically turn to RPG character classes page numbers in a PDF by passing that page number to a for loop which executes gotoNextPage the appropriate number of times.  The case structure contains the actual enum value, but it represents the potential problem of searching through the case to find the appropriate case number associated with the enum.  However, as you do have the Enum name in the case structure label bar, it's fairly easy.

[GPeople]

WTF

It is 2019 and this is not implemented yet!?!?!

Based on the comments I guess LabVIEW is not really used for programming low level protocols like SNMP. 

Speaking of which, why is SNMP not included in the LabVIEW data communication VIs????

[Darren]

National Instruments will not be implementing this idea in LabVIEW 20xx. It is currently the feature backlog for LabVIEW NXG.

[JimB.]

So where does the recent announcement regarding the end of NXG leave this? Any chance it could be reopened?

[wiebe@CARYA]

As I heard, all items closed 'because of NXG' will be opened again.

It might just need some time. Or maybe they missed it...

[AristosQueue (NI)]

> As I heard, all items closed 'because of NXG' will be opened again.

Change "will be" to "may be". They are being reconsidered, but no guarantee that any given item will be reopened.

My personal suspicion is that this one will remain permanently declined. That's just my bet, not an official statement from NI.

I would like to have this feature, but it is hard for me to make the business case for it. Every time I try to present it to people, it comes out sounding like it just solves some minor bookkeeping issues for which easy workarounds exist (see Carlnath's last post, for example). I believe that isn't really the case, but that's what it sounds like. Combine that with the issues I mentioned in my previous post (complex to design, very low customer usage expected) -- it was a long shot to ever get it into G. Even keeping it in the NXG backlog was hard to justify.

What we need to build this case is more side-by-side diagrams showing the problems that sparse enums solve, with some clear annotations for what new capabilities sparse enums enable for G developers. Those diagrams are very hard to come by because making them requires someone "programming with Paint" or other graphics utility.