Non colliding names for LVClass static dispatch methods

[Tomi Maila]

Hi,

I'd really love to see the following change in LabVIEW OOP. Currently static dispatching class methods cannot have the same short name as the methods in any of the ancestor classes. As a result, if I've a static dispatch ancestor method say Initialize.vi, then I cannot have a VI with the same name in my descendant class.

As an example consider a parent class Root and a child class Node from Aristos Queue's linked list example. Consider that you wanted to be able to Initialize objects of both classes. To make naming convention uniform, it would be natural to call these initialization methods Initialize across the hierarchy. It would make it easier for the class user to identify the initialization method to be used. However this is not possible. Adding a Initialize.vi to both classes would break the classes resulting in broken arrow even when the VIs are static dispatch VIs. Still the VIs would have unique qualified name i.e. long name of the form Class Name.lvclass:Initialize.vi.

The advantages of allowing methods at different levels of class hierarchy to have same names are:

• Method naming would be simpler and uniform method names could be utilized across the classes for similar functionality
  
• It would be easier for the class user to identify functionalities such as Initialize, Create or Close
  
• Call Parent Method primitive could be extended to function also with static dispatch method of the same name. The linking can be done at compile time and this would only be short cut to finding the parent method with a same name. This would be valuable for initialization where a constructor method such as Initialize could easily call parent constructor with different connector pane.
  

The only downside of allowing multiple methods in the hierarchy to have the same name is that this would limit the class developer of changing a static dispatch method into a dynamic dispatch method later on.

If you support this idea or are against it, please comment. We can gather feedback for LVOOP R&D team...

[Justin Goeres]

QUOTE(Tomi Maila @ Oct 15 2007, 03:14 AM)

To make naming convention uniform, it would be natural to call these initialization methods Initialize across the hierarchy.

Generally speaking, I feel the same way you do. However, there's a benefit of not allowing colliding Static Dispatch names in a class hierarchy that I've discovered in my own work.

To work around the name collision problem, I typically name all (or most of) my Static Dispatch VIs according to the convention <CLASSNAME> Initialize.vi. For example, Kitchen Sink.lvclass would have Kitchen Sink Initialize.vi or KS Initialize.vi. The (unintended? ) effect of this is that I can usually tell whether a VI in my hierarchy is Static or Dynamic Dispatch just by looking at its name.

That having been said, just being able to call the VI Initialize.vi and be done with it strikes me as a step forward. A separate wishlist item of mine would be to have a little badge on a VI's icon to indicate whether it's Dynamic Dispatch, but I don't want to threadjack .

[Aristos Queue]

The decision to not allow static VIs to share names up and down the hierarchy was made for user benefit initially -- it avoids a programming error that was found to be common in C++ of forgetting to make a function "virtual" (the C++ equivalent of "dynamic dispatch") and thinking you had overriden it in the child class when in fact you had only shadowed it. Function shadowing was something we really wanted to avoid because it is simply baffling even to advanced programmers what is going on with a function. So, if you name two functions the same name, we assume you want to be doing dynamic dispatch and we break the VI until you either set the VIs to be dynamic dispatch or rename one of the VIs.

So, we made that decision, and I do think it is generally a good one. It is in line with the other decision to prevent function overloading, where multiple funcitons of the same name have different conpanes. Since the parent class has already defined a function of a given name, arguably that name is already taken in the child's namespace (depending upon whether you think of inheritance as actually inheriting an API vs inheriting rights to invoke the parent's API).

Having made the decision, the LV implementation has now enshrined that decision in several places, and changing it would be nigh on impossible. Not completely impossible, but sufficiently so that it would take a massively compelling reason to change it as we'd have to drop a bunch of other feature work in order to address the code. I've tried talking to multiple early adopters about this issue, and most have come off like Justin -- they don't really like it, but see enough advantages to keep the current mechanism, particularly when they see what can happen with C++ function shadowing.

(Note that all of this is separate from the conversation about whether a private-scope static dispatch VI should steal from the child's namespace. I'd like to fix that bug, but there's some technical difficulties doing so; it too has become kind of enshrined, although less so).

[Tomi Maila]

QUOTE(Aristos Queue @ Oct 15 2007, 07:22 PM)

The decision to not allow static VIs to share names up and down the hierarchy was made for user benefit initially -- it avoids a programming error that was found to be common in C++ of forgetting to make a function "virtual" (the C++ equivalent of "dynamic dispatch") and thinking you had overriden it in the child class when in fact you had only shadowed it. Function shadowing was something we really wanted to avoid because it is simply baffling even to advanced programmers what is going on with a function. So, if you name two functions the same name, we assume you want to be doing dynamic dispatch and we break the VI until you either set the VIs to be dynamic dispatch or rename one of the VIs.

Unlike in C++, a static method of a child class in LabVIEW wouldn't shadow its parent method because LabVIEW can always use fully qualified names to make the call. Text based programming languages suffer from the fact that users don't want to write long fully qualified names. In LabVIEW one doesn't need to write but simply drop a corresponding method to block diagram.

[Aristos Queue]

QUOTE(Tomi Maila @ Oct 15 2007, 01:36 PM)

Unlike in C++, a static method of a child class in LabVIEW wouldn't shadow its parent method because LabVIEW can always use fully qualified names to make the call. Text based programming languages suffer from the fact that users don't want to write long fully qualified names. In LabVIEW one doesn't need to write but simply drop a corresponding method to block diagram.

I disagree. I went to type out reasons, but they basically boil down to "It confuses me to have multiple VIs of the same name that are in the same hierarchy but have no relation to each other." Sure, LabVIEW always knows what VI is being referenced. Yea for LabVIEW. It's me, the programmer, who can't keep it all straight sometimes.