It might be nicer to have a simpler interface to read/write routines for class references. The fact that the bundle/unbundle is now an asynchronous operation needs to be displayed as does some sort of error terminal.
The To More Specific node is already a locking node when downcasting DVRs of class types. The Unbundle and Bundle nodes would likewise become locking nodes. Perhaps a lock glyph of some sort should be drawn on the nodes as a reminder to developers so they aren't surprised by a deadlock.
David: Yes! I've wanted this feature too. I'll add that I want similar behavior when calling class methods that take by value objects.
Aristos: Yes, a lock (maybe instead of the arrow) glyph would work. Another option would be to add some sort of small halo around the node, having the same width and color of the IPE Structure walls. This wrapper/halo could also have error handling (error in / error out) terminals, so that the invalid reference condition can be handled gracefully, programmatically.
> I'll add that I want similar behavior when calling class methods that take by value objects.
Because you could only bundle or unbundle on a limited set of VIs (i.e., the members of the class) you as the developer can decide whether to use this quick shortcut in a VI or whether you should throw down an Inplace Elt Struct because you need to hold the reference for a long stream of operations -- such as an unbundle, modify, bundle. But when you're exposing an API, you have to think ahead to all the possible permutations of operations that someone would want to do as a set. That is something to be largely discouraged -- expose out the by value operations and let the users of the references make their own decisions about what needs to be done as a single operation. In fact, if I have any reservations about this idea, it is that someone would get used to using this "easy" bundle and unbundle on their references and end up right back in the read-modify-write race condition problem.
Jim: Your visual depiction isn't my objection. My objection is
a) If I have three method calls in a row, each one will unlock and re-lock the value. This is unnecessary overhead if there isn't anything in parallel, and it is possibly wrong behavior if there is something in parallel (ie. the ref should stay locked for the duration of all three operations).
b) Just because a VI has an object in and an object out does not mean that the object out should necessarily be written back to the reference. And there may be multiple objects out... which is the right one? (Yes, its an edge case, but I have to design to handle the edges.)
I really feel that conversion from reference to value and back again is something LV the language should stay out of and leave to the programmer to explicitly declare locks and unlocks. For any given class, you, the user, are free to design an API that is intended to be used by reference, but I really feel that for the general case, anything LV does in the "ease of use" arena is a major disservice to the "leading user to get it right" arena.
Jim's second illustration might be less necessary if there was an easy way to automatically generate (and document. And give them icons which would show this) VIs which do this. Even then, having such a structure would create less "noise" and make things more consistent between different programmers.
All this, of course, doesn't invalidate or answer the points you brought up.
