Allow "To More Specific Class" to operate on arrays

[BertMcMahan]

So this isn't a huge deal, but it would be nice if we could put an array of classes into To More Specific Class to convert all of them to the more specific class. There are handfuls of functions that work well on both arrays and single elements (the Math functions, Close Reference, etc).

Error Out would need to become an array as well. I can't think of anything at the moment that this might break, or any poor patterns it might enable, it would just save a For loop here and there. I made a quick example vim just to illustrate, but it'd be nice if it was part of LabVIEW core.

[AristosQueue (NI)]

I floated making this change once... worked up a bit of a prototype. The users I talked to became divided about what the node should do in the fail case. When only a subset of the input objects fail the type check, what should the node output?

a) an empty array and a single error cluster that says some objects failed

b) a non-empty array that contains only the objects that succeeded the downcast and a single error cluster that says some objects failed (with one person arguing it should be a warning).

c) a non-empty array that contains the same number of elements as the original array, with default objects in the positions that failed and a single error cluster that says some failed.

d) same as (c) but with an array of error clusters, mixing "no error" and "error"

e) same as (c) but with an array of error clusters of only the failures

f) same as (b) but with an array of error clusters, mixing "no error" and "error"

I'm sure there's some other permutation.

Eventually, I concluded that the pattern variations were so myriad that it was better to leave the node alone and let people code the solution they needed in each case. With the introduction of VIMs, this becomes even easier.

I'm not saying LabVIEW shouldn't do this... I'm just saying I don't know what the right answer looks like.

[BertMcMahan]

Fair enough. The vim I made up does d), as it feels to me the most "complete". With all of the other ones, there's no way to know which specific element failed the conversion check without doing it manually in a For loop, which defeats the purpose of the exercise. If you need to know if Any failed, not just Which one failed, you can throw a Merge Errors onto the end of it. Filtering the array to only get the ones that passed would be fairly simple as well with an additional For loop autoindexing the array with an autoindexed/conditional output.

Basically I feel like if you went with d), you could implement the rest down the line. You coudn't do that with the other options.

Anyways, it's a small thing and I already have a .vim that does what I need, so it's no big deal either way. I just like thinking/learning about this kind of thing. Thanks for the info about the history of this request.

[AristosQueue (NI)]

> there's no way to know which specific element failed

> the conversion check without doing it manually in a For loop

Apparently, for a whole lot of people, this is a "who cares" scenario... it's useful info while debugging, but not for the execution of the program. And generating an array of errors is arguably a waste of memory. And there's the question of behavior in the "all succeeded" case... do you generate an array of all "no error" or an empty array? If an empty array, it means you have to check for that special case downstream.

I thought I knew which one would be the best option; I no longer do. It'll be interesting to hear other comments. If there is a consensus, it would be easy enough to ship a VIM these days with LV.

[fabric]

My biggest use case for this would be type-testing a bunch of objects so I can then dynamic dispatch on the "good" ones in a sub-tree of the inheritance hierarchy*. For that use case I would want (i) only the objects returned that succeeded in downcasting, and (ii) a single error/warning cluster which I would probably just ignore anyway. That's a definite vote for (b).

If I wanted 1-for-1 output objects and/or an array of error clusters then I would just wrap the prim in a FOR loop...

*It always feels like the "proper" thing to do would be to add the appropriate abstract methods to the base class, but that is often undesirable when the class hierarchy is deep. You just end up with a glut of abstract methods at base level that are not relevant to most of the other child classes.

[CantankerousBullMoose]

---

a) an empty array and a single error cluster that says some objects failed

b) a non-empty array that contains only the objects that succeeded the downcast and a single error cluster that says some objects failed (with one person arguing it should be a warning).

c) a non-empty array that contains the same number of elements as the original array, with default objects in the positions that failed and a single error cluster that says some failed.

---

I'm strongly against all the 'array of error cluster' because there's nothing you can do with an array of errors that doesn't un-do the purpose of this thing. With an array of errors I could:

1) iterate through the errors with a For loop and handle each one individually in some way, possibly modifying the object array in some way based on the errors

2) do (1) but wrap it in a subVI to keep my BD clean

If I'm already doing (1) or (2), this really isn't saving me any time any more, and it's probably not allowing me to even move ugly code somewhere more convenient; An array of errors is a significant departure from the normal LabVIEW error paradigm, and the arrays of objects and errors are at least somewhat coupled in most of the suggested implementations. So, at the end of the day, I think I'd want to deal with those arrays right when they're generated rather than hope that someone down the line understands/remembers what to do with them. 

I can't see any version of option (c) that's useful without an array of error clusters. Modified array elements with no easy way to dig them out probably just ends up with an array that I can't use anyway, since I don't know what's in it anymore.

So that leaves option (a) or option (b). I would argue that option (b) is actually a different, separate feature that has other, as yet unwritten goals. For instance, in @fabric 's usecase, I could see a desire to output the 'bad' objects as a separate array with their original type preserved. To me, that gives (a) a slight edge, but I could be happy with it either way.

---