LVOOP code distribution

[Intaris]

Semi-hypothetical question.

If I have a hierarchy of LVOOP classes which provide a certain functionality, what's the best way to go about distributing the code with an eye on preventing further inheritance from the entire hierarchy.

In other words, how can I stop anyone from using my code base and extending it willy-nilly (and possibly doing something I don't want them to do).

Do I need to use a constructor which is set to "Community" scope?

Does anyone have experience of inputs on this?

Shane.

[tst]

No experience, but in any case, this seems kind of contradictory to the concepts of OOP. If I understand correctly, what you basically want is to be able to mark the entire hierarcy as "non-inheritable-unless-you-have-the-password". I can't say I thought about this, but it would seem to me that such a feature would have to be enforced by the IDE.

You might be able to a must-override VI to the base class which will generate something which the base class can use to guarantee that the object is valid (e.g. a hash of the class), but you would need to manually change this for each class to avoid someone simply copying the VI from one of the existing classes. Also, you'd need to call the verification VIs in your code so they generate errors and screw up the code. Not very useful.

Another alternative would be to hold a static list in the parent, but that sounds even worse.

I think we'll need a concrete example to be able to better imagine the exact use case. What's the actual problem with someone extending by inheriting?

[Intaris]

Static list is unattractive. to say the least.

Like I said it's semi-hypothetical.

One possible scenario would be having a toolkit and offering free and extended versions of it.  From a code maintenance point of view, it would be good to have a shared base but to have the extended features only available in the paid-for version.  If the product was based around the fact that the majority of the blood sweat and tears were spent impelmenting the base class then the entire marketing would be built up on the premise that the ability to USE the code would be free, but the ability to use the extended version or to extend it yourself is something which is reserved for paying customers.  This way you build up a market with the users of the free version, thus driving demand for the paid-for version.  AFAIK this is technically very difficult with LV.

I don't believe it's contradictory to the ideas of OOP at all.  I'm pretty sure most modern programs are written in OOP but they're not generally exposing their class structures the way compiled LV code does.

[tst]

You could add an idea to the idea exchange - prevent inheriting this class (and any of its children) unless the user has a password.

It should probably not be technically difficult to implement, although I assume the current format of the .lvclass file does not hide the inheritence part very well (if memory serves, it's binary, but it's probably not super complicated), so users could probably override it manually unless the format can manage it.

[Intaris]

I was thinking of adding it as an idea, but I thought maybe there's already a way I'm not aware of.....

[shew82]

classes that are within an LV Application (EXE) are not exposed to third parties, just like any other programming language....

If you're talking source code, until something else comes a long, probably your best bet is to use DVR classes (ie have your parent class pass in/out a DVR of the object) and set the properties so that only the class can create the DVR and that child classes have to have their references created by the parent class (check both boxes in the class's inheritance options - I cant remember what they're called right now and dont have LV 2009 in front of me).

Alternatively, you could create a DLL (shared library) distribution and bury your class hierarchy in that.

[Intaris]

Would this also apply to a .lvlib distribution?

A big advantage of .lvlib is that it can be recompiled by the IDE allowing for one software to be used with different IDE versions and also on different platforms.  Dlls require three different compilations for three platforms (for one LV version).

I'm almost sure what I am looking for is possible.  I've never actually made an LVOOP Lvlib (never made an lvlib at all) so I'm a real N00b.

Shane

[tst]

Building a DLL creates wrappers. An LVLIB does not. It simply packages the VIs. There is something in 2010 which might help, but I haven't used it, so I can't comment.

Also, thinking about this some more, my original suggestion does not seem THAT bad. You would basically need each class to have a "return hash" VI (the hash will be a constant generated semi-manually at creation time). Then, when you call some shared functionality, the base class will have a static dispatch VI which re-generates the hash and checks it against the one from the subVI. If they don't match, it will pop up a nag dialog.

Not super elegant, requires some manual work, but I believe it should work. It would not prevent people from extending the class, but the usability will be hurt. Of course, this will also have some performance implications, which may be an issue.

Also, now that I think about it, there is one feature which is supposed to be in 2010 (unrelated to the previous one), which would probably suit your needs precisely. Like the other feature, I haven't used it.

[shew82]

lvlibs are basically the same as classes but without inheritance or the class cluster. You just get the name spacing and private/public accessibility options. I'm not sure if you can inherit from a private class (a class inside a lvlib that is marked as private) or not but if you can't then I guess that would achieve your goal.