Downstream polymorphism example for Idea Exchange comment

[Intaris]

Im lookkng for a purely class-internal feature.  Nothing that would affect code using such objects.  Everything i want is possible today, just cumbersome.  I will write mpre later, i hate typing on tablets.

[AristosQueue (NI)]

Parent class defines a property named X with type Y.

If the child class is going to have a property X, then it must have type Y -- because it already has one that it inherited. What you are asking for would give the child class *two* properties, both named X. The first one would be the one inherited from the parent with type Y. The second would be the one the child added with type Z.

What you are asking for would be a bug. We deliberately do not allow the child class to have two different properties with the same name.

So, yes, if the two classes have a parent-child relationship then any properties they have must have the same data type. You can override the way that value is calculated by making the implementing method be dynamic dispatch, but you cannot make it a different type.

[Intaris]

I dont want two properties with the same name. That idea came from your proposal to solve my problem.

I dont want dynamic dispatch.

I want static methods with different names.  All doable today. No problems.  What i want beyond that is simple syntactic augar. It should change nothing else.

If i am implementing ANY kind of system where children add data (in my case user events) which are elsewhere needed strictly typed, i need, as a programmer, to know which method of the parent class implements its part of the functionality i require so that the child can expand on it.  Again, all static vis, different vi names, no conflicts.  All i want is an internal note or tag so that the ide can in essence tell me - this is the vi you are looking for in order to expand this part of the functionality.  Kind of like the call parent method but not dd,  not an oop aspect at all.

I come from a wonderfully software-engineering absent background and something like this may or may not exist elsewhere, i have truly no idea. I tried reading up on covariance and i certainly think this is NOT what i am lookkng for.  Im not sure becase i didnt quite understand what covariance would mean in a lvoop context.

Again, im simply looking for some IDE comfort, not neccessarily a change to any oop paradigm (that i am aware of).

Sorry for makkng my posts generaly unclear.  The correct terminology is like a foreign language to me sometimes.

[tst]

I think now I understand better. What you want is essentially something like the following, correct?

Essentially, you're talking about extending* the API of a class by inherited classes, yes?

* Terrible term, because it refers to inheritance in some languages, but it seems fairly accurate here. Maybe expanding or augmenting is a better term.

[Intaris]

Tst, thats pretty much it. The exact details of the implementation are unclear to me regarding what would be best but your image certainly conveys my idea pretty well.

[AristosQueue (NI)]

Let me see if I can restate it in my terms.

You have class A.

You have class B inheriting from A.

You have a method 1.vi on A. It has N outputs.

You want to do something to create a "1.vi" [although it need not have that name] on B and associate it with A such that if you drop A's 1.vi and wire a B to it, you get N+M outputs, where M is more outputs contributed by B.

Yes?

I have never heard of any such thing in any programming language, nor have I ever felt the need for any such, but that doesn't mean it isn't a valid need -- text is often quite limited in what it can do compared to a reactive graphical environment, and my imagination may be limited by past experiences.

Let's use the term "expand" -- you're expanding the number of terminals that a method has if it is wired with a child class.

Going back to your original post in the Idea Exchange... how does the expansion of terminals affect the selection of methods that was your original problem you were looking to solve?

[tst]

Incidentally, you can do something like this today using XNodes or Express VIs, as they allow you to adapt to what you do.

The basic idea would be that you decide on a convention (let's say that the VIs are all named __Events XXX.vi, where XXX is the class name). Then, you write the XNode to script the calls to all the existing VIs when you change the wiring and change the amount of outputs accordingly.

Since my understanding was the XNodes aren't really going to be developed anymore (maybe AQ can somehow wink and comment on that), the other option is express VIs. This isn't as nice, because it doesn't auto-adapt (you would have to double click it to call the config VI) and since it can't have a variable number, so you would have to wrap the values in a cluster or limit the number of possible outputs. The advantage it does have is that it's officially supported (there should be a wizard in Tools>>Advanced).

[Intaris]

Youre getting closer, but no cigar yet. Your example alters the behaviour of the class in code using the class. I definitely do not want that.  The new functionality should only be visible or usable within the class itself.

I dont want an expandavble terminal at all even though tsts example looks nice.  I would (as i have stated many times) like something akin to call parent method (but free from any oop connotations that may have) where I can simply (in the class properties) state that for class feature X, this is the vi responsible on this level. Then, instead of having a multi-node as in your diagram, the prpgrammer can easily access the responsible vi for the previous level of the hierarchy and process its output accordingly.  I would tend to look at a single vi with a single connpane where any concatenation or appending is done subsequently at each level.

Class a.get properties.vi would return data A.

Class b.get more properties.vi can access A through my new pseudo call parent method and add data B to it to output A+B.

Class c.get even more properties can access A+B trhough my new pseudo call parent method and adds data C to output A+B+C.

This is simply how I would aproach this.

Without having some kind of directions as to which vi of the previous generation is responsible for a given chain, the programmer must have intimate knowledge of the parent class which i feel is not optimal.

My original idea of a polymorph vi was an incomplete attempt at solving this problem.  Admittedly its not a major problem but i run into it often enough to wish there was a better way.

[AristosQueue (NI)]

What you are describing is something entirely different from a parent-child relationship. It is not an unreasonable request, but it isn't something that can or should exist between parent and child. If a parent class has a "get properties.vi", then the child class also has a "get properties.vi". In other words, someone could directly call "get properties.vi" on your B. Or upcast B onto an A wire and then call "get properties.vi". Either way, it won't be doing the work of "get more properties.vi".

The nature of the parent-child relationship is such that a child IS a parent. What the parent defines as the right interface for a given property is BY DEFINITION the right interface for the child class. It is only between unrelated classes that you can even meaningfully say "I'm going to define two different interfaces for this property on these two classes".

There may be some other type of relationship that can be developed... something like "class B remaps class A", but I cannot find any analog to this in any programming environment, likely because this setup would actually be impossible in textual languages -- when a text programmer wants to invoke a function, they have to declare the function parameters they are passing in, where as in LV, the editor environment can present different conpanes based on conditions in the environment. Text programmers do not type in a function name and then fill in a mad-libs of parameters presented by the editor. Instead, they type in a name and assert the parameters and then the compiler finds the best match for the parameter set.

Having said that -- it would not be something that would ever work between parent/child, which leads me back to my original post about how to do this with property nodes between unrelated clases. You want a small extension to that that says, "This VI knows that it is the implementer for property X so that there can be a node on the diagram that says "whatever property I am, call that same property on my 'parent' class", only it isn't a parent class, it is much closer to a HAS relationship instead of an IS relationship.

I'll play around with it and see if I can codify some more around it.

[Intaris]

---

@AristosQueue (NI) wrote:

What you are describing is something entirely different from a parent-child relationship. It is not an unreasonable request, but it isn't something that can or should exist between parent and child. If a parent class has a "get properties.vi", then the child class also has a "get properties.vi". In other words, someone could directly call "get properties.vi" on your B. Or upcast B onto an A wire and then call "get properties.vi". Either way, it won't be doing the work of "get more properties.vi".

---

What you write is technically correct but kind of misses the point. I think you are assuming my proposal is a lot more complicated than it really is.

What i want is to be able to tag a class method with a name.  Then i implement another vi in a child and assign it the same tag.  All I want the ide to allow me to do is issue the command to call the vi with the same tag from the parent class.  The vis do NOT override each other.  They are completely unrelated in a classic oop sense beyond the fact that they exist in different levels of the class hierarchy.

Someone directly caling "get properties" on B is no problem.  Perhaps the user only requires that interface.  Each individual vi is in itself complete.  It is possible and feasible to call any vi from the current class up to its base class if that is what is required.  There is no requirement for an object cast to A to execute "get more properties.vi".  I  fact i would rather state it is explicitly not desired to do so.  Casting an object B or C to A and then caling "get properties.vi" should correctly behave exactly the same as calling "get properties.vi" on a real object A.

I state again for posterity.  Each vi for a given function (in my case an incremental set of user events which increases qith each child class. Tst named it API and i think that is apropriate for my particular function) am referring to has a different vi name and data type.  They do not inherit from one another.  This works fine today and the only change I am proposing is if the programmer needs the parent version of the vi (in a functional sense, not oop sense) then it would be rather nice if i could set the class properties in such a way that the IDE can tell me which vi this actually is.  Since the names are different, some cunfusion and thus errors could occur when manualy choosing the vi.  Hence the ability to somehow mark the vis with a tag or similar within the class properties.

We should perhaps move away from the term "properties".  The property node only entered the equation when AQ made a suggestion.  The presence of a property node is not integral to my idea at al.  In fact, given the  urrent information i think focussing on property nodes is a hindrance to understanding my idea.

Again, my idea is really kind of trivial and could conceivably be done with scripting.