Have Dynamic Dispatching terminals accept Data Value references of the class or any child class.

[KvZ]

When you’re making a By Reference LabVIEW Object using a Data Value References (DVRs) the user of your class would need to embed each Dynamic Dispatching VI inside an In Place Element Structure (IPE). Or you have to create wrapper VI for each method but this undermines the advantages of LVOOP Inheritance.
 
The idea is that a DVR containing a LabVIEW Object wired to a Dynamic Dispatching Terminal is equal to calling the Method VI inside the IPE structure like illustrated below.

Message Edited by Support on 01-15-2010 04:39 PM

[AristosQueue (NI)]

fabric:

tl;dr : I'm not opposed to improving the by-reference situation. I'm opposed to this naive solution to that problem. There are other possibilities that are worth exploring. And it isn't me against the world. It is me trying to work with the few power users to find a better solution to the problem than one that has such extreme downsides.

Longer:

You already have enough rope to hang yourself... write the wrapper VI (doesn't even need to be a member of the class). Mark it as inline and when you build your applications/DLLs, it's as good as anything we would do behind the scenes. We don't need more rope to hang in the air. What we need is a way to hang in the air without strangling.

Many people have taken my opposition to this "just wire the reference to the method call" as being opposed to supporting by reference classes. I have some sympathy for people who want to use by-reference types. It is the same sympathy that I offer to those who use global VIs -- they're easy, they just don't scale. You call DVRs an advanced feature. That's wrong. They are a base feature. An advanced user would move *away* from them, not toward them. The DVRs are the crutch for users who are used to working in reference environments. As beginner tools, we have to structure them to avoid as many problems as possible. I am sympathetic to making reference objects work correctly. The *simple* idea of "just let the refnum wire to the method" has massive downsides.

All the work that I have been doing with Actors is in direct response to research into by-reference classes and trying to fix their fundamental flaws. If we could introduce something like actors as a language primitive, where the messaging and dynamic method registration is handled, and where the compiler is aware of them for the purposes of optimization, then we have a model for references that is resilient to many of the issues that by-reference types introduce. It is one of several research thrusts I've been working on.

There's also the possibility of introducing a true by-reference hierarchy, something like introducing a new fundamental base class for all reference types of "LabVIEW Reference Object". In such a hierarchy, all the dynamic dispatch terminals would be DVRs of the class and you would never have a by-value wire anywhere. Even Bundle/Unbundle would take the reference directly. Such a class would be known to the LV compiler and would have a contract of greedy amalgamation of locks or something like unto thereof. We could annotate the method call nodes themselves with graphical switches to control whether the function was locking or non-locking on the object reference itself, and we could track through the call chain whether this call chain -- not the thread, since many threads may execute parts of a LV diagram -- is the one that has a particular object's lock, thus allowing one method to call another method. I have many unanswered questions about this solution.

Finally, I've been looking at monads from functional programming languages, which is a technique of having functional code that has reference side-effects in a way that isolates the calling code to see if there's anything we can salvage from there. Monads are a topic spanning several semesters of CS courses, so I'll skip any summary here and tell you if you're interested to go dig around on Wikipedia.

You said, "Fundamentally, I disagree with the position "this will be abused so let's not do it"."  My attitude is more of "users need to do X; let's enable X but not using solution Y which has major downside Z." In many cases, that has meant pushing out the ability to do X several LV versions while we find the alternative to Y. Just implementing the obvious solution undermines LabVIEW's ability to serve its users. If we have too many "use at your own risk" functions, LabVIEW ceases to be a language in which programmers can just focus on their work and turns into a language where programmers are constantly paranoid about the computer environment, the way they have to be paranoid in C or C++. The languages of JAVA and C# are both managed languages, and both of them have limitations on what can be done in those languages, sometimes to the frustration fo programmers working in them. But the people frustrated are a relatively small number of users. That's *exactly* the case with by reference classes in LabVIEW -- in my experience, the workarounds we have today stress out my power users, but my novice users are more likely to not try to come up with the "clever architecture" but just use the IPEs around their function calls -- and they end up being more successful than the power users in this domain who keep fighting LabVIEW.

If we're going to elevate this aspect of data sharing, I want to do it in a way that doesn't create a bunch of poorly-thought out reference types that each one incrementally makes LabVIEW harder and harder to use.

[BrianGShea@NGC]

AristosQueue,

I like your idea of 'introducing a true by-reference hierarchy' or Static Class in LabVIEW. I think you are saying that the complier would treat the wire as a DVR to the object, and any method or property accessing the object would obtain an exclusive lock on the object until complete. Controlling access in cases that require reading a value, modifying it and write it back out side of the class would require an IPE wrapper placed by the user around the code.

I think this entire concept could be implemented in LabVIEW right now by encapsulation. One class contains a DVR for the encapsulated class. Each property/method of the encapsulated class would need to be duplicated by the encapsulating class. It is messy and doubles the number of classes and VIs required to implement the solution, but should be a close approximation. This link (https://decibel.ni.com/content/docs/DOC-18320) explains it how to do so. I know AristosQueue, that you have probably read or even written this, however, others that stumble on to this page my not have found it.

I don't particularly like the Property read on DVR of a Class. It is confusing and allows coders to think they have exclusive access to a value that they do not. I would much rather see a better solution.