Allow References to be Wired into Case Selectors to Check for Validity

[JackDunaway]

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

[AristosQueue (NI)]

> Checking for the validity of a reference is useful if the reference can go bad

> and you want to silently correct the issue by obtaining a new reference.

True. I did say I suspect there are other valid use cases out there -- those were the only two I could think of off the top of my head. Do the use cases you can think of overcome my concerns about the parallelism and the excessive work done by nodes to check the refnum?

[JÞB]

I think its a pretty good expansion for the case structure and would be especially useful for vi server refnums, file paths and file refnums. 

[WG-]

It is nice but... isn't it applicable to all comparison items... such as

- Is empty string?

- Is decimal digit?

- Is printable?

- Is whitespace?

- Is empty array?

- Is not a number?

I think we should stick with the old method.

[AristosQueue (NI)]

Just a thought... adding this "check if refnum valid" behavior to all refnums for the Case Structure would get in the way of the Case Structure having a "select based on class of refnum" behavior, which is also on the Idea Exchange here. Which feature would people prefer? I recognize that this one has more Kudos, but this one has a decent existing workaround. The other idea does not.

[tst]

If the two are mutually exclusive then the other idea is definitely more valuable.

[PhillipBrooks]

Interesting. I commented on this LAVA post today, then happened across this suggestion. Aristos makes an important observation about misusing the "Not A Refnum" primative that can create a race condition in your application.

http://lavag.org/topic/15546-are-you-misusing-the-not-a-refnum-function-and-putting-your-app-at-risk...

How might this idea be affected by this observation?

[Daklu]

There are lots of LV power users who have kudoed this idea.  I'll risk the tar and feathers and say no, this is not a good idea.  I posted my response on LAVA before I saw Phillip had linked to this idea, so I'll just summarize my argument here for those that don't want to read through the entire LAVA thread.

Pretesting a reference before performing an operation on that reference is a race condition and should be discouraged.  It's not just the Not A Refnum function, it's any sort of pretesting used to make execution branching decisions.  Your users may never encounter the race condition, but it is there.  If you're operating on a reference, attempt the operation then do a postcheck for errors.

[JackDunaway]

I have a tendency to agree that this idea could promote "seemingly safe" but actually bad practices, and after AQ's warning in 2009, I actually came to realize this is probably not a good feature to add to the language. Granted, it would be acceptable and syntactically slick to execute code in the <Not a Refnum> case, but the tendency for developers to place code in the <Valid Refnum> case makes it dangerous (even my snippet to promote this Idea makes this mistake!).

I respectfully suggest this Idea be Rejected on the grounds of potentially causing more problems than the syntactical sugar is worth (and also because it complicates the case selection of class types, a much cooler and more useful Idea)

[X.]

So how can we kudo the suggestion of removing the suggestion? When will we get "like/dislike" options? Has this been patented by Facebook and Google?