08-30-2010 08:04 AM
Stepping back from the issue;
The same issue is present with all (?) type defs, not only enums. Using classes where we would previously use type defs is the work-around.
AS to wiring enum to case structures;
When using classes instead of enums the "wiring to cases" is being done for us automatically behind the scenes.
Still waking up,
Ben
08-30-2010 08:20 AM - edited 08-30-2010 08:21 AM
Ben wrote:The same issue is present with all (?) type defs, not only enums. Using classes where we would previously use type defs is the work-around.
Right, this is the conclusion I have come to also - the use of typedefs is superceded by classes. It's bad news to use a typedef inside of the private data of a class - that typedef should be it's own class - if for no other reason, to leverage the language feature of stored mutation history of the data structure.
So, enums?? It's maintenance suicide to NOT typedef an enum, yet enums are too powerful/elegant to completely give up for the sake of LabVOOP. That's why this thread hinges upon the mutation history of (typedef'd) enums.
RE: A class whose sole data member is the enum: I tried some simple techniques to make this work, but they all boiled down to "this is more work/code than I can possibly justify for a stupid enum". Additionally, since the enum must be typedef'd, I didn't even try to see if the class would maintain the enum items mutation history for a non-typedef'd enum.
RE: dynamic dispatch vs. case structure: I'm hesitant to introduce dynamic dispatching where a case structure would suffice. It's simpler, more readable, have fewer VI's when performing SCC operations... basically, dynamic dispatch is reserved for things a case structure simply cannot achieve. And enums live in the same sections of code that case structures live in, hence my reluctance to give up the enum for the sake of LabVOOP.
08-30-2010 08:42 AM
@JackDunaway wrote:
Ben wrote:The same issue is present with all (?) type defs, not only enums. Using classes where we would previously use type defs is the work-around.
Right, this is the conclusion I have come to also - the use of typedefs is superceded by classes. It's bad news to use a typedef inside of the private data of a class - that typedef should be it's own class - if for no other reason, to leverage the language feature of stored mutation history of the data structure.
So, enums?? It's maintenance suicide to NOT typedef an enum, yet enums are too powerful/elegant to completely give up for the sake of LabVOOP. That's why this thread hinges upon the mutation history of (typedef'd) enums.
RE: A class whose sole data member is the enum: I tried some simple techniques to make this work, but they all boiled down to "this is more work/code than I can possibly justify for a stupid enum". Additionally, since the enum must be typedef'd, I didn't even try to see if the class would maintain the enum items mutation history for a non-typedef'd enum.
RE: dynamic dispatch vs. case structure: I'm hesitant to introduce dynamic dispatching where a case structure would suffice. It's simpler, more readable, have fewer VI's when performing SCC operations... basically, dynamic dispatch is reserved for things a case structure simply cannot achieve. And enums live in the same sections of code that case structures live in, hence my reluctance to give up the enum for the sake of LabVOOP.
Clarification:
Please don't take my words as a solution!
I am just another traveling LOOPing along with you in the hopes that I can learn something through your experiences.
AS to enums within a class and not exposed to other classes;
Yair's suggestions are good LVOOP or not. There used to be a common pratice in coding that says never to remove any code but only replce or enhance. If the enums are only exposed to developers then typos can be tolerated.
I am not there yet but I seem to be using enumerated cases less often these days with Dynamic dispatching filling the gap. But these types of changes are expensive in already developed code.
Trying to help more than I hurt,
Ben
08-30-2010 11:29 PM
If your interest is piqued enough to have read this far, you're going to want to vote for Maintain Mutation History as part of Enum Type Definition