7 replies to this topic

[lvb]

Is there a way to control which VIs of a LVOOP class are exported (visible) in a packed project library? I would like to expose only a few methods of a class.

Note: Some of these are dynamic dispatch which cannot be set to Community or Private in the class.

[Aristos Queue]

To control what is visible, set the access scope. The dynamic dispatch VIs can be set to protected, which is the only other meaningful scope for dyn disp -- it doesn't make sense to have a dynamic dispatch method that cannot be overridden by children.

There is a valid use case for creating a wrapper class that has a reduced set of methods that wraps an inner class. This is done a lot in various programming languages to create a read-only version of the class, so the wrapper class only has methods for reading values, not writing them. You would then hide the core class inside the packed project library (making it private to the library) and expose your wrapper class only.

[lvb]

To control what is visible, set the access scope. The dynamic dispatch VIs can be set to protected, which is the only other meaningful scope for dyn disp -- it doesn't make sense to have a dynamic dispatch method that cannot be overridden by children.

Hence the reason for my post. Dynamic dispatch VIs seem like a catch 22 with lvlib scope. You are forced to wrap the class to hide just a single VI.

There is a valid use case for creating a wrapper class that has a reduced set of methods that wraps an inner class. This is done a lot in various programming languages to create a read-only version of the class, so the wrapper class only has methods for reading values, not writing them. You would then hide the core class inside the packed project library (making it private to the library) and expose your wrapper class only.

For large projects, this seems like a lot of work to hide one or two dynamic dispatch VIs. It would be nice to control what VIs are visible/exported in the lvlib properties.

Any thoughts? I may put this into the idea exchange...

[Aristos Queue]

Hence the reason for my post. Dynamic dispatch VIs seem like a catch 22 with lvlib scope. You are forced to wrap the class to hide just a single VI.

Why isn't protected scope sufficient hiding?

For large projects, this seems like a lot of work to hide one or two dynamic dispatch VIs. It would be nice to control what VIs are visible/exported in the lvlib properties. Any thoughts? I may put this into the idea exchange...

That would be unusual among the world's OO languages. I'm not saying it's a bad idea, but when none of the major OO languages that I know of do it, I always have to ask why. Scope is not one of those areas that is impacted by dataflow.

[lvb]

Why isn't protected scope sufficient hiding?

Because the VIs are still visible in the Packed Project Library (they are not hidden):
Since they shouldn't be used, the user will question why they are visible.

That would be unusual among the world's OO languages. I'm not saying it's a bad idea, but when none of the major OO languages that I know of do it, I always have to ask why. Scope is not one of those areas that is impacted by dataflow.

Isn't this a feature of the Packed Project library (that does not exist in other languages)? The PPL is used for "interface" and it would be nice to separate the "presentation" from the class itself. This would reduce a whole lot of "busy work" wrapping classes.

Thanks,
Brian

[mje]

There is a valid use case for creating a wrapper class that has a reduced set of methods that wraps an inner class. This is done a lot in various programming languages to create a read-only version of the class, so the wrapper class only has methods for reading values, not writing them. You would then hide the core class inside the packed project library (making it private to the library) and expose your wrapper class only.

To me a better approach would be to just support private inheritance.

/ducks

[Aristos Queue]

Isn't this a feature of the Packed Project library (that does not exist in other languages)? The PPL is used for "interface" and it would be nice to separate the "presentation" from the class itself. This would reduce a whole lot of "busy work" wrapping classes.

PPLs are not a part of the LabVIEW language. They're just packaging for functionality, no different in many ways to a .zip file. The PPL is not a presentation layer or any other formal aspect. It's just a tool for getting VIs to load faster.

When you ask for changes to scope, that addresses language features, which means changes to the run time behaviors that would impact dev environment and run time environment alike, regardless of packaging.

To me a better approach would be to just support private inheritance.

A good write up of why composition is preferred to private inheritance:
http://www.parashift...nheritance.html

[lvb]

PPLs are not a part of the LabVIEW language. They're just packaging for functionality, no different in many ways to a .zip file. The PPL is not a presentation layer or any other formal aspect. It's just a tool for getting VIs to load faster. When you ask for changes to scope, that addresses language features, which means changes to the run time behaviors that would impact dev environment and run time environment alike, regardless of packaging.

It sounds like this would be a major addition (or would never happen), but it would be nice if the lvlib supported a presentation layer