Why this to more specific Class does not work?

[V_T_S]

Any idea?

Test Project.zip

[Shaun Hayward]

Any idea?

You are trying to go the wrong way around: you should be using the "To More Generic Class" function

[V_T_S]

You are trying to go the wrong way around: you should be using the "To More Generic Class" function

Still does not work -

[drjdpowell]

Still does not work -

The "To More ____ Class" functions don't actually change the class of the object (so, as you created a Child object, you got the child's "multiply" function by dynamic dispatch). They actually just change the type of the wire. A Child object flowing on a Parent wire is still a Child object. I've found this very confusing myself.

-- James

[V_T_S]

At one particular instance of my application, I want to force the child to call the parent method (irrespective of having dynamic dispatch terminal – addition function in this case).

Is anyone aware of any work around for this type of usage?

Thanks,

Vidula

Edited August 8, 2011 by Vidula S

[Shaun Hayward]

There is a class property that you can set to enforce that child VIs unconditionally call the "Call Parent VI" node?

Or, you could create two VIs, one static and one dynamic - that way, when you want to ensure that the parent's VI always gets run, you could use the static VI?

[Francois Normandin]

At one particular instance of my application, I want to force the child to call the parent method (irrespective of having dynamic dispatch terminal – addition function in this case).

Is anyone aware of any work around for this type of usage?

Thanks,

Vidula

The problem comes from your choice of inheritance hierarchy.

Inheritance should always be a "Is A?" relationship.

In your case here, multiplication is not an addition... so multiplication should not be the child of addition. They could both be children of a parent class named something like "Arithmetic operation". Addition is an arithmetic operation, multiplication is an arithmetic operation.

Now it does not mean that you cannot perform an addition in one instance and a multiplication in another, but this should be implemented differently and never forced arbitrarily from the outside.

Consider this example where you have a parent class that is a generic 2D geometry where you have stored a collection of points that delimit any geometry (array of points).

You could have a child class for a triangle, which would always have 3 points. And you could have another child for rectangles, which would have 4 points.

When you call a method that is common to both children, for example "Measure Area", you will be calling the parent method which will dynamically dispatch the appropriate child method depending on the object type that is propagating on your wire. The implementation of the children methods will differ.

[V_T_S]

There is a class property that you can set to enforce that child VIs unconditionally call the "Call Parent VI" node?

Or, you could create two VIs, one static and one dynamic - that way, when you want to ensure that the parent's VI always gets run, you could use the static VI?

Call Parent VI – Does not work at application level. It works only when used in the child class methods.

Creating static and dynamic VI’s of the same code is a duplication of code. I was hoping for a better option. But I guess there is no other option in this case.

Thanks for the reply.

[Shaun Hayward]

Creating static and dynamic VI’s of the same code is a duplication of code. I was hoping for a better option. But I guess there is no other option in this case.

Don't forget: There is nothing stopping you putting your static VI inside your dynamic VI - at least that way your actual code is only written once.

[Norm Kirchner]

Is this a situation in which you only ever want to call the parent VI?

If so, then just don't make that VI for the child.

If, as you state " I want to force the child to call the parent method"

Assuming that you want to selectively call the parent or the child, then you need to have and input to the VI that declares which one to call.

Then from within that VI, take that input and either exectute what the child has for code in one case, or within the other case call the parent function using the 'Call parent method' primitive.

This will give you exacly the type of behavior that your wanting, you just need to add an input to the function, or add a piece of private data to the parent and then call a function that sets that value, then within the function your trying to selectively choose, read that value and do the same kind of selective execution of code as mentioned above.

Best

~,~

[PaulL]

As François suggested, you might want to reconsider the class design itself rather than trying to force a specific method to run in some strange manner. If you explain what it is you are trying to do, perhaps we can help devise a straightforward way to achieve the goal.

[V_T_S]

There “Is A?” relation in the design, this is just a dummy example I made for the submission.

It is one of the scenarios where everything works perfect but the one application need little twist/change in the standard code and rather than rewriting/redesigning/duplicating I was looking for some solution.

I like the idea of Norm, instead of making a massive change I can selectively call the required method.

Thanks everyone.

Edited August 8, 2011 by Vidula S

[jgcode]

At one particular instance of my application, I want to force the child to call the parent method (irrespective of having dynamic dispatch terminal – addition function in this case).

Is anyone aware of any work around for this type of usage?

I had this question when I first started using LVOOP and was trying to do some JAVA examples in LabVIEW (where JAVA supports what you are trying to do).

Check out the thread, AQ replied - its a good read.

[Daklu]

There “Is A?” relation in the design, this is just a dummy example I made for the submission.

I've never really like using "is a" as a measure of whether a class should inherit from another class. I think it's too loosely defined and easily leads to design problems that are hard to resolve. The Circle-Ellipse Problem is an example where it breaks down.

I like the idea of Norm, instead of making a massive change I can selectively call the required method.

That could be the right business decision and I'm not criticising it, but be aware it is probably not the correct architectural decision. At the very least you'll be losing some readability. More likely the problem you've run into indicates an error in your design. If this code is going to be supported and extended over the long-term you'll probably end up wishing you had fixed it.

Personally if I had to make a quick fix I would have gone with Shaun's solution. Move all the code from Parent.Operate into a new method, Parent.Operate(Shared), and have Parent.Operate simply delegate to Parent.Operate(Shared). I can't say definitively it's a better solution, but instinctively it makes more sense to me.

[V_T_S]

For the time being I am going with Norm’s suggestion (business decision )just because it an easy fix for me.

After reading the link sent by jgcode, I completely agree that some architectural change is required in my code. Thank you for that additionalinformation.

Regards,