Why is the Continuous Measurement and Logging Sample Project in LabVIEW 2012 using Strings instead of Enums as queue commands?

[AStankov]

Hi!

I noticed that the Continuous Measurement and Logging Sample Project in LabVIEW 2012 is using strings instead of enums as queue commands. I wonder if there is any good reason for that?

Regards,

Anguel

[mikeporter]

1. It was originally written before LV had enums.

2. The developer didn't know any better, or was in a hurry and didn't want to take the time.

Mike...

[AStankov]

---

@mikeporter wrote:

1. It was originally written before LV had enums.

2. The developer didn't know any better, or was in a hurry and didn't want to take the time.

Mike...

---

I am not really convinced that this is the case. This is a very new template project included in the latest LV 2012 only, so #1 can't be true. Regarding #2 the project uses so complex mechanisms that I don't believe that it was done in a hurry or by people who don't know better. I believe that there must be some other reasons, e.g. that strings are easier to handle or similar, although they are not as efficient as enums...

[Dennis_Knutson]

Why do you think that a string based state machine is less efficient?

There has a been a long debate as to whether to use strings or enums in a state machine. If you care, do a search. There are pros and cons to both so pick the one you like best.

[JÞB]

I actually Asked Simon Hogg that exact question at NIST.  The answer was "From a SE standpoint the user should not need to know anything about the code it is calling.  An Enum breaks that paradigm since the caller must know the type def. "  or words to that effect. 

[Mark_Yedinak]

---

@JÞB wrote:

I actually Asked Simon Hogg that exact question at NIST.  The answer was "From a SE standpoint the user should not need to know anything about the code it is calling.  An Enum breaks that paradigm since the caller must know the type def. "  or words to that effect. 

---

Actually, that is a pretty bad answer for not using the ENUM. Using strings requires the caller to know more about the internals of teh VI since it must know teh exact strings to use. An ENUM defines the valid choices.

[JÞB]

---

@Mark_Yedinak wrote:

---

@JÞB wrote:

I actually Asked Simon Hogg that exact question at NIST.  The answer was "From a SE standpoint the user should not need to know anything about the code it is calling.  An Enum breaks that paradigm since the caller must know the type def. "  or words to that effect. 

---

Actually, that is a pretty bad answer for not using the ENUM. Using strings requires the caller to know more about the internals of teh VI since it must know teh exact strings to use. An ENUM defines the valid choices.

---

In that example the code thows an error if the string is not defined.  I didn't say I agree....Only what was presented to me by the maker of the thing. From a practical approach enums are much more user friendly IMHO.  But, the argument for strings does exist.  I'll probably regret not persuing the conversation during break.

[Joseph_Loo]

It is assuming you know the defintion of the enum. To do the job properly, the enum should be type def. That will bring in another slew of problems, e.g. conflict of the type definition.

[AStankov]

Thanks for the hints. To me it looks like by using strings one can simply wire commands easier, without having to update enum typedefs. The drawback is of course the risk of typing errors. Additionally with strings one can have commands with the same name e.g. "Start" or "Stop" that perform similar things in different consumer loops. Therefore they can be typed once and wired to multiple queues and then the corresponding consumer loop knows what to do when it receives that string command from its queue.

Regarding the discussion above: Comparing strings is always slower than comparing numeric values, i.e. enums, in any language. But compared to other heavy tasks like updating front panels etc. this probably cannot be noticed.

[SimonH · Accepted solution]

First of all, the enum vs string debate is probably the LabVIEW version of vim vs emacs. There are good arguments on either side and I doubt there'll ever be a "winner".

A brief summary of our reasoning for the current state of the sample projects:

1. We used enums for the state machine because it is self contained. A state machine will never tell itself to move to a state it doesn't know about. Since we (as the programmer) know all the possible states using an enum allows us to enlist the compiler to help us avoid mistakes at edit time (since you can't mis-spell an enum and LabVIEW can tell if you aren't covering all cases in a case structure, etc.).
   
   Enums provide more protection and rigidity by making sure everything checks out at edit time. This often makes them the "default" recommendation that we make.
   
   
2. We used strings for the queued message handler because the message producer and message handler could be independent processes that are reused and/or swapped out. Strings avoid the need to have the compiler be able to link the commands and pushes that responsibility to the programmer. This enables you to develop sub-components independently as long as you agree to a series of string commands that you can handle -- you don't need to share a "messages.ctl" or "states.ctl" file. It is conceivable that a message handling loop recieve a message that it doesn't understand, at which point you could decide to either silently ignore it or raise an error (as we do in the template). Strings also make it easier if you wanted to swap the LabVIEW queues out with a TCP implementation to vacilitate network or intra-process communication where the other endpoint may or may not be written in LabVIEW.
   
   Strings provide more flexiblity (i.e. you can add new commands to an existing system via plugins, you can pass parameters as part of the string, etc.) at the expense of pushing potential errors to run-time and putting more of the responsibility on the programmer.
   
   
3. The Actor Framework presents a 3rd option -- using classes as the messages. For me this combines a lot of the benefits of both enums (strictly typed, edit time errors), and strings (flexible, expandable) but with the downside of being a little less transparent (you need to understand OO, be comfortable navigating through a multitude of VIs, understanding inheritance, etc.).

I'm sure there are other reasons others within NI had or saw as we vetted the templates and sample projects internally but these are my reasons. We know we can't design for every situation out there -- our goal is to get some useful templates in front of new users to make them aware of what well-thought out LabVIEW programs look like. Experienced users will know their applications better and I hope they feel free to modify what we provide or create their own templates when they feel it is necessary. (On a side note please share what you come up with -- a  community of experts sharing templates would really help all of us LabVIEW users.)

Best regards,

Simon