In Place Element Structure Support for Objects

[kegghead]

LabVIEW allows classes to use the IPE structure via the cluster unbundle/bundle pair. Generally I avoid this because it's poor form for object oriented programming: it bypasses any logic I've put in place in the get/set methods. If I use the IPE on classes, when time comes to change my get/set logic, I no longer have a singular bit of code to modify.

With the advent of properties for classes in LabVIEW 2010, I propose that the IPE structure should be adapted to allow the use of any properties a class has defined:

The IPE structure should:

• Honor the scope of the property methods (that is allow private properties to be used in class methods, but not elsewhere for example).
• Allow seamless use of Data Value References of objects, similar to how property nodes already do (though in this case error terminals would need to be involved).

I kind of think this one is more important than my variant post. I contest that LabVIEW currently has no support for objects in the current IPE since using unbundle/bundle on the class is generally a bad idea.

[JackDunaway]

What if the property is read only or write only? The IPE would necessarily be restricted to properties with both read/write. Also, the IPE guarantees atomicity for the Read/Modify/Write, which type of functionality might better be suited for a method.

Take a look at Selectable Class Data Member Scope. I'm not supporting that specific Idea (any more) or calling this a duplicate, but I think it stems from the same annoyance and room for improvement for a simpler type of accessor.

[AristosQueue (NI)]

Not possible.

Well, I mean, syntactically, sure, it could be done, but semantically its impossible. Let me explain...

The Inplace Element Structure provides a way to guarantee that the same memory location is accessed at both ends of the wire. In other words, it is more than a syntactic way of saying "do these two paired instructions." It is specifically, "Access this data using instruction A and then set this data using instruction B."

With the properties of a class, there is no single data location to access. The output of the Read operation may be the result of some calculation, not merely unbundling a field from the class. The input of the Write may be decomposed to set multiple fields. It is even possible that the two operations are not symetrical -- the data fields might not be the same fields used in the two operations.

In short, there's no semantic reason to add this to the IPE, and it would be misleading to claim there was some sort of memory optimization taking place if we added it for purely syntactical reasons.

[kegghead]

"The output of the Read operation may be the result of some calculation, not merely unbundling a field from the class"

Very good point, I completely overlooked that. I suppose I withdraw this idea.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.