Making member private breaks class, why, how?

[LAVA 1.0 Content]

Why does changing the scope of a VI within a class to "private" break the class?

In the attached zip you will find a folder complete with project and required files.

I started by defining a generic class and then create accessor (?) for all of the values in the class.

Whenever I set any of the VI within that class scope to "private" the class breaks (they all dynamic).

So how do I set a accessor(?) as private?

Not knowing LVOOP I was guessing that I keep everything private and only make protected or public what I absolutely needs to expose. I have to admit I am a complete loss as to what I am doing wrong.

[Edit] Are there rules about dynamic dispatch and private not going together?

[Edit again] After creating a new project blah blah blah, I manually set connectors as required and issue went away. So private and dynamic do not mix. I am not sure exactly what dynamic really means (I thought it was a way to let LV choose a polymorphic instance at run time) but I am not sure what that has to do with breaking when it is made private.

Ben

feeling very LVOOP stupid at this point.

[Omar Mussa]

QUOTE (neB @ Jun 9 2008, 12:32 PM)

Whenever I set any of the VI within that class scope to "private" the class breaks (they all dynamic).

Haven't looked at your code but FYI private VIs cannot use Dynamic Dispatch. I think that is your problem. This is a desired/expected behavior. You wouldn't expect private VIs to allow ancestors to override them.

[LAVA 1.0 Content]

QUOTE (Omar Mussa @ Jun 9 2008, 03:46 PM)

... This is a desired/expected behavior. You wouldn't expect private VIs to allow ancestors to override them.

Thank you Omar!

OK I'll trust you on it being expected. Now I I have to do is figure what ancestors are and and what override means.

Ben

PS: please excuse my dumb questions on LVOOP. I have been reading and I'm trying but OO is still a forign language. Learning the machine instruction set of a KL-10 seems easy to getting this old hardware guys head around the terminology.

[Omar Mussa]

QUOTE (neB @ Jun 9 2008, 12:56 PM)

PS: please excuse my dumb questions on LVOOP. I have been reading and I'm trying but OO is still a forign language. Learning the machine instruction set of a KL-10 seems easy to getting this old hardware guys head around the terminology.

There are some good links to documentation on the LVOOP wiki here:

http://wiki.lavag.org/LVOOP

[Francois Normandin]

I'm still a newbie at LVOOP too , but it is my understanding that you can use "Protected" for Dynamically dispatched VI's. Protected would be "Private" to everybody except for child classes. You can override protected methods.

[Aristos Queue]

VIs that use dynamic dispatching can be public or protected, but not private.

This is one of those decisions that could have been made either way and really comes down to my team's philosophy of design. There are good arguments on both sides (and, in fact, C++ made the opposite decision and allows private virtual). Our reasoning goes like this:

A VI marked as "private" is contracted to never be called outside of the class.

A dynamic dispatch subVI call chooses at runtime which of several VIs to actually invoke. Each of those VIs is at a different level of the hierarchy.

There's no way for the contract of "private" to be kept if you allow dynamic dispatching to work -- somewhere there must be a caller that is not inside the class that is invoking the method, and thus is occassionally dispatching ot another level of the class.

C++ made the opposite decision, under the argument that "private" for a virtual (aka dynamic dispatching) function means "only the parent class can call this method set, but each level of the hierarchy is free to define the behavior for that private call".

Neither decision is wrong, but, in my not-so-humble opinion, one is a lot easier to explain to folks.

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Jun 9 2008, 06:56 PM)

VIs that use dynamic dispatching can be public or protected, but not private.

This is one of those decisions that could have been made either way and really comes down to my team's philosophy of design. There are good arguments on both sides (and, in fact, C++ made the opposite decision and allows private virtual). Our reasoning goes like this:

A VI marked as "private" is contracted to never be called outside of the class.

A dynamic dispatch subVI call chooses at runtime which of several VIs to actually invoke. Each of those VIs is at a different level of the hierarchy.

There's no way for the contract of "private" to be kept if you allow dynamic dispatching to work -- somewhere there must be a caller that is not inside the class that is invoking the method, and thus is occassionally dispatching ot another level of the class.

C++ made the opposite decision, under the argument that "private" for a virtual (aka dynamic dispatching) function means "only the parent class can call this method set, but each level of the hierarchy is free to define the behavior for that private call".

Neither decision is wrong, but, in my not-so-humble opinion, one is a lot easier to explain to folks.

Thanks in advance* for that reply!

I am working my way through all of the documentation I could find on LVOOP. The above question came up as I was moving from page 3 to page 4 of the http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/creating_classes/' target="_blank">Creating LabVIEW Classes article.

The LAVA Wiki articles are next in my stack of print-outs.

Ben

* Thanks in advance since it will take me some time to fully conceptualize the reply.

[shoneill]

QUOTE (neB @ Jun 10 2008, 03:42 PM)

Thanks in advance* for that reply!

I am working my way through all of the documentation I could find on LVOOP. The above question came up as I was moving from page 3 to page 4 of the http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/creating_classes/' target="_blank">Creating LabVIEW Classes article.

The LAVA Wiki articles are next in my stack of print-outs.

Ben

* Thanks in advance since it will take me some time to fully conceptualize the reply.

Ben, I feel your pain.

I also recently had my "AHA" moment with OOP in LabVIEW (Interchangeable spectrometer drivers). I'm plagued by thoughts of where I can use it since....... :ninja:

I think it's a great addition to the LV repertiore.

Shane.

PS DOesn't LVOOP kind of make IVI redundant?

[Aristos Queue]

QUOTE (shoneill @ Jun 10 2008, 10:24 AM)

PS DOesn't LVOOP kind of make IVI redundant?

The following is commentary from a developer who has never used IVI, never written an IVI driver, never looked at an IVI specification. I've just sat next to IVI folks for the last several years and overheard conversations. Many of them had input into how LV classes were implemented in LabVIEW.

My understanding is that IVI, as a specification of an API, is not invalidated by OOP but rather it is fulfilled by OOP. We can now define the framework VIs that IVI calls for once, in a parent class, and then have each driver be a class which overrides the framework with the specifics needed for its purposes.

This is an area where I personally believe LV classes could lead to a major reduction in the amount of code that a driver author has to write. I would be very happy to hear of any success stories that driver authors have using LVClasses in this manner.

[Tomi Maila]

QUOTE (Aristos Queue @ Jun 10 2008, 08:29 PM)

This is an area where I personally believe LV classes could lead to a major reduction in the amount of code that a driver author has to write. I would be very happy to hear of any success stories that driver authors have using LVClasses in this manner.

This is not exactly a driver but very similar though.... We wrote a very general file format interface using LVOOP and wrote an implementation for HDF5 files. This we have been using for a year now but about two weeks ago we needed to add support for proprietary TIFF image archive format based on MS JET databases and collection of TIFF files. Writing a new plugin that implements the class interfaces took a few days. Now our application framework fully supports this new format and no changes needed to be made anywhere outside the plugin. For us, a file format plugin is a collection of LabVIEW classes in a lvlib library. We load the plugin dynamically at runtime based on the selected file format when writing files or based on the file extension when reading files.

We have plans to write new plugins for various other file formats including TDM and TDMS.