Make class data accessor VIs without error terminals available through Bundle/Unbundle

[candidus]

Often error terminals aren't necessary for class data accessor VIs. We can create accessor VIs without error terminals but then we can't make them available through property nodes. We have to call these VIs explicitly on the BD.

It would be great if we could use Bundle/Unbundle instead:

Notive the small wrench on the Unbundle node. That means there's still an accessor VI for parentData behind the scenes. childData belongs to the current class so that's a mere unbundle operation. The BD readability has improved.

[Intaris]

Not all accessors have only one output or input.  It's completely possible to have multiple inputs and outputs which is hard to handle with a normal property node.

[tst]

One problem with this syntax (apart from the fact that it's pretty alien to the way we current write code in LV) is that it doesn't define what happens to the class output of the VI. You could say it just evaporates into the ether, but that won't work if the object was modified inside the VI.

A more friendly syntax would probably be if the property node could call VIs without error IO. This has its own problems, but the most naive implementation would simply be to call the VI in sequence and possibly to skip the rest of the calls if an error was raised.

[candidus]

Maybe I should define what I mean when I say "accessor VI": I have only VIs in mind that just contain a single Bundle or Unbundle node, nothing else. A read accessor is not supposed to modify the class data in any way. This could be enforced by removing the class output.

[Norbert_B]

I have the feeling that there is a good idea coupled with a very odd one.

The good one:

Accessing the data of the parent representation of a child object without the need of calling dedicated "get" functions by using the unbundle function on the child object itself.

This is a feature which could be handy. Instead of the spanner icon for indication of "property of parent class" i would use the "dot notation" common to .NET:

<parentclassname>.<propertyname>

The odd idea:

What the heck has above to do with error input/output???

Norbert

[candidus]

No, the accessor VI is still required, otherwise we'd have public data. That isn't what I propose. Btw, .NET is a good example for non-public data because that's how properties work: You have a getter and a setter behind the scenes but as a mere user of the component you don't recognize them. My idea is some kind of alternative property node syntax, and that's where we come back to error terminals: Error terminals are required for property nodes but in many cases you don't have to wire them. As a user of the class you don't see if you have to wire errors without looking at the accessor's source code. That's why I propose another syntax for property access when error terminals are unnecessary: This way we could easily distinguish acessors that handle and return errors from the ones that don't.

[Norbert_B]

You shouldn't mix "unbundle" with "property node". So it either a property node or an unbundle (the access to parent data), but it cannot be both in a single node.

You are correct that class data is private and an access to this data outside the object is more than questionable. On the other hand, it seems natural that child classes, who INHERIT the properties of the parents, have a generic access to the data fields the parent class defines as the child class do share them because of inheritance.

If the node encapsulates dedicated accessor functions or if the class data is extended to be of "protected access scope" doesn't matter much in a functional view for this suggestion.

In such an aspect, i find the suggestion a good one, ponder to give a kudo for it. But i hesitate as i see the label and description misleading as "error cluster" really has no place in this idea....

Norbert

[candidus]

That's odd: The error wiring was my intention of this idea 🙂

Regarding protected access: I think we will never have that. The accessor VI has several purposes, it's useful for debugging, for example. So my idea is essentially about another syntax to call an acessor VI that was created without error terminals. I don't see a problem with mixing bundling/unbundling and property accessing: Think of it as a guarded bundle/unbundle operation.

[AristosQueue (NI)]

Duplicate.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Property-Node-Style-Bundle-and-Unbundle-Element/idi-p/...

And I think you'll like the details of the other idea better.

(You can argue that the other idea isn't an exact duplicate, but, trust me, it is insofar as the suggestion is "do something to improve the utility of data accessors including those without error terminals".)

[candidus]

Thank you! I just kudoed the other idea. But I'm still not sure whether it's really a duplicate, because the idea you mentioned is about clusters in general, not about LVOOP.

[JordanG]

Dupe: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Property-Node-Style-Bundle-and-Unbundle-Element/idi-p/...