Single dispatching, multiple dynamic dispatch inputs

[LAVA 1.0 Content]

Currelty there can be only one dynamic dispatch input terminal in a dynamic VI. If you want to compute for example A+B where both A and B are objects of Numeric class, only either A or B can be a dynamic input terminal and the other must be a regular terminal. It's natural to assume that A+B is computable only if both A and B are of the same subclass of the Numeric class i.e. complex + real cannot be computed togerher but integer + integer can be computed.

What I suggest is the following. There could be multiple dynamic dispatch terminals in a VI. However only the first one would be used for dynamic dispatching, no double dispatching would be allowed (not at least in the beginning). The clue is that LV would require at compile time all of the dynamic dispatch terminals to be of the same class type. This doesn't naturally guarantee that the terminals are of the same type at runtime, but makes it much more unlikely. In addition, the LV would add runtime type chekcing code to verify that all the dynamic terminals are of the same class type before executing the VI. If they were not, a runtime error would be generated. This way the VIs could be a little simpler as the user doesn't need to explicitly typecast all the classes to the same class type. The downside is that if a type mismatch runtime error occurs, it's very hard to handle programmatically. Of course the runtime error could be written to error cluster control (not necessarily connected to connector pane) of the VI to allow the VI to handle the runtime error.

[Aristos Queue]

Ug. Sounds horribly complex. What in the world are you architecting where it matters whether or not the two input terminals have matching runtime types???

[LAVA 1.0 Content]

Ug. Sounds horribly complex. What in the world are you architecting where it matters whether or not the two input terminals have matching runtime types???

Something very very simple indeed. I'm encapsulating numeric data type into a class. But as I know that OOP is all about reusability, I derive my numeric type from a general class Numeric. Numeric is an interface class. It has dynamic methods such as (in pseudocode):

Numeric Add(dyn Numeric A, Numeric B)

Numeric Negate(dyn Numeric A)

Numeric Substract(dyn Numeric A, Numeric B)

In all these three methods, terminal A is dynamic dispatch terminal as is the return value terminal. Terminal B is not. Numeric class has an implementation for method Substract that relies on Negate and Add, namely A-B := A+(-B).

Since class Numeric is only a interface class, I create one or more implementations of this Numeric class. Let's call one implementation Integer, which implements an unbounded Integer type. So we need to create override methods for Add and Negate. They will look like the following:

Integer Add(dyn Integer A, Numeric B)

Integer Negate(dyn Integer A)

As you can see, we now have a problem with Add, since the inputs are of different class type. But we just want to add A and B of both Integer class. So we need to at runtime typecast B to Integer and return an error if this fails. It would be easier and cleaner to program if we could force both terminals to of Integer class type in this override VI. So I'd like to see the following interface for the Integer class Add method:

Integer Add(dyn Integer A, dyn Integer B)

So it would be possible to mark multiple input terminals as dynamic dispatch inputs. Then in the override VI, these inputs would not be of parent type but rather of child type. This forces the child class user to connect wires of correct type to the VI and the class developer doesn't need to typecast input B into Integer every time he/she uses this kind of pattern.

I hope I made myself clear. I've a habit of thinking that others naturally understand what I mean, which of course is often not the case

[robijn]

Numeric Add(dyn Numeric A, Numeric B)

Numeric Negate(dyn Numeric A)

Numeric Substract(dyn Numeric A, Numeric B)

With OO you would have the addition as part of the class. So if I have a numeric I can add something to it.

Numeric.Add( Numeric A );

which adds A to the object's own numeric.

You are treating the object as a functional library. That's OO abuse

But if I understand you correctly you want to use dynamic dispatching to decide which of the following methods you need to select in order to do the correct addition.

Numeric.Add( Double d );

Numeric.Add( ComplexDouble s );

But this is function overloading. Using different arguments to reach different functionality. Besides, function overloading is a compile-time-only feature, not a run-time feature (like dynamic dispatching). Maybe some languages do actually support this dynamic function overloading, I don't know of one.

What you want can be reached with "normal" OO features in the following way:

You could define an Addable class of which the objects you want to add should inherit, like with Java's "implements" relationship. Then you can create a function:

Numeric.Add( Addable A );

The implemented methods in each class inheriting from class Addable should perform some conversion. Because that class would have only virtual methods. That's why Add can work.

Obviously these theoretical examples are quite unreal. Noone wants to use OO to add two doubles . But the mechanism can be used for real-world things as well.

I think the good functioning of the core OO system is far more important than all kind of extensions like function and operator overloading, macros and templates... Currently I consider it not advantageous to use LVOO because the core functionality is unpractical.

Joris

[LAVA 1.0 Content]

You are treating the object as a functional library. That's OO abuse

No, I was just using different notation for the same thing... Instead of writing "Integer.Add(...)" I wrote "Add(dyn Integer,...)", which means exactly the same thing. However I prefer the "dyn" specifier in LabVIEW context as it is closer to LabVIEW implementation of OOP.

However, there is no such thing as OOP abuse, if something can be implemented more easily and elegantly using OOP then it should be used. OOP patterns are often oversimplified in many books as the books are often targeted for people learning OOP. For OOP newcomers certain patterns should be discouraged so that these people really learn how to use OOP correctly. After you have passed this stage and know how to use OOP well, then you can begin to "abuse" OOP to achieve more interesteing functionality. If you read Java programming blogs, most advanced users are exactly trying to overcome Java limitations by "abusing" OOP.

[Aristos Queue]

For OOP newcomers certain patterns should be discouraged so that these people really learn how to use OOP correctly.

Heh... at this stage of the game, anyone claiming to be past the learning stage of OOP with LabVIEW is not being honest with themselves.

As far as the feature request -- you can code the dynamic type tests to validate inputs easily enough. Adding them to the language would be a VERY VERY long term feature, if at all.

[Dan Bookwalter]

anyone claiming to be past the learning stage of OOP with LabVIEW is not being honest with themselves.

Past the learning curve , hell i am still stumbling around tryng to FIND the curve

[Chris Davis]

Past the learning curve , hell i am still stumbling around tryng to FIND the curve

amen to that!

[TG]

amen to that!

Hehe You know I am not even remotely yet a contributor to this forum,

but I've been studying you guys and Goop for more than a few days (most of it right here in

this Forum.)

All I can say is Please keep up the chatter!

The more you guys talk the more I begin to understand how all this works.

Thanks!