Polymorphic Object??

[elset191]

If Init.vi is unique to the child you will have to do something like this.

I've never tried it, but I assume you can replace the Parent constant with a child constant and avoid the second To More Specific.  Of course, this kind of defeats the purpose of OOP if you do that. 

If Init.vi is dynamic dispatch, you will do something like this.

Note in this case that we are dynamically loading the child object onto a parent wire.  Because the actual type of the object is child, it will call hte child's Init implementation if it is provided.

[MacDroid]

"in this case that we are dynamically loading the child object onto a parent wire"

Is this because of GetName?

Is Getname a method of the child, parent, or LV Object? If the later where do find it?

[elset191]

---

@MacDroid wrote:

"in this case that we are dynamically loading the child object onto a parent wire"

Is this because of GetName?

Is Getname a method of the child, parent, or LV Object? If the later where do find it?

---

No, that's not why.  GetName is just a red herring that i was too lazy to correct.  GetName and GetColor should be taken as Write Visa and Read Visa in your images.  So to answer your question it is a method of the parent, which is also implemented as dynamic dispatch in the child class.

Dynamically loading the child onto the parent wire is done by virtue of providing the path to the child class to Get LVClass Default Value and the To More Specific with the parent object constant wired to it.

[MacDroid]

Hmm...so I'm back to where I started, kinda. When I wire from WriteVISA to Init it creates an error.

Parent has:

WriteVISA

ReadVISA

Child has:

WriteVISA(inherited, not implemented in child)

ReadVISA(inherited, not implemented in child)

Init.vi(with dynamic input/ouput nodes for object wire)

[elset191]

---

@MacDroid wrote:

Hmm...so I'm back to where I started, kinda. When I wire from WriteVISA to Init it creates an error.

Parent has:

WriteVISA

ReadVISA

Child has:

WriteVISA(inherited, not implemented in child)

ReadVISA(inherited, not implemented in child)

Init.vi(with dynamic input/ouput nodes for object wire)

---

As your project currently stands, the dynamic inputs on Init.vi don't matter at all  (it may if you add parent or child implementations in the future.)

All you need to do to get the error to go away is do like I did in the first picture of my previous post.   Here it is again.

[MacDroid]

Yes, that does work, except, this whole exercise is because the class in the filepath IS a child...I don't know which of the hundred he might be so the To Specific is not an option.

The goal is to have a folder full of children each representing a meter/power/supply/scope/etc, 10 today, 20 tomorrow, 30 different ones the day after. But only have a child .lvclass for each and have the main app load whatever is there.

What am I missing?

[elset191]

---

@MacDroid wrote:

What am I missing?

---

An Init implementation in your parent class.

Seriously though, if you provide all of the functions you will need in the parent class, any child class will fit right in directly.  That's the whole beauty of dynamic dispatching.  In this case your parent class will more or less serve as an abstract class.  Your parent class will be what is called a "fat class*" which means it has all of the VIs of its children even if it doesn't use them itself

*Not sure if there's a technical term for that, but that's what we called it in school

[dkfire]

---

@MacDroid wrote:

Ok, so I'm missing something. In the above example the class spec'd in the class path is a child, with Init.vi, of Obj_Equipment. But the path between WriteVISA Name and Read VISA Name is apparently not a child.

---

How is you Wrte VISA Name.vi set up ? does it have dynamic dispatch connectors ?

[MacDroid]

That works if I know all the VI's the parent will ever need.

But it may change every time the avaialble equipment changes.

That's why I am trying to have the child only know about the differences.

[elset191]

---

@MacDroid wrote:

That works if I know all the VI's the parent will ever need.

But it may change every time the avaialble equipment changes.

That's why I am trying to have the child only know about the differences.

---

If instruments come along in the future with new features you're going to have to edit the code regardless to add this functionality to the calling VIs.  Your main VI won't know anything about these new features even if your new class has them until you add them on the block diagram. While you're editing your main VI to handle these new features, go ahead and add them to the base class.

With any existing functionality you can populate your base class with any and all of the VIs that you will use.  

Now, am I missing something?