Preventing class VIs from showing up on overrides list

[_carl]

Is there any way to prevent class VIs from being overridable by children?  Specifically, I'd really like for certain VIs to not show up in the overrides list when I create a new "VI for override" from a child.

Maybe I'm missing something, but it doesn't appear that any of the access scope options allow for this...

[tyk007]

I assume you're talking about dynamic dispatch VIs rather than static dispatch ones (which implicitly can't be over-ridden). There is currently no way to set a dynamic dispatch VI as "final" - there are even some who suggest that the very idea of such a feature implies a systemic flaw in the design.

Can you be more specific about why you wouldn't like it shown? 

[wiebe@CARYA]

See Allow for "Final" specifier on Class Override and Add support for "Uninheritable" methods and classes in LabVIEW

[wiebe@CARYA]

EDIT: wrong thread, deleted.

[_carl]

Yep, I'm specifically referring to dynamic dispatch VIs, and as wiebe pointed out, it looks like there've already been requests filed for this feature on the idea exchange.

[Kyle97330]

Well then I guess I would go a bit deeper in asking your motivation here...

Is it really just "annoying" that they are on the list?  If so... sorry.  You just have to try to be less annoyed.

Or, is it that you have other developers that you don't want to be overriding your class members past a certain point in the inheritance?  If so, you might have an alternative that won't stop them from creating the inheritance in code, but will at least stop them later:

1. Start by putting VI documentation in place that says not to override a certain VI past a certain class.

2. On the class method that you want to be "final", set the "item settings" for that VI to always require descendants to call the parent node.

3. When the "final" VI runs, have it check the call chain.  If the item in the call chain immediately prior to the call is the same VI file name but a different class, add an error on the error chain stating that they shouldn't have done that.

[_carl]

While it is "annoying", it's also what you described: not wanting developers to override class members past a certain point in the inheritance.  Sure, you can enforce blocking overrides as you described, but that experience isn't ideal: it requires extra work developing the base class, and it's not as simple for child class developers to pick up.

I'd like to make this experience as user-friendly as possible.  Having other developers only see the two overrides I'd like them to override, as opposed to having a list of dozens of possible base-class overrides in the overrides drop-down would be an objectively better experience.  It reduces the risk of errors and minimizes ramp up for new developers.

Annnyway...all suggestions are much appreciated, and I think I've got the answer I was looking for: it's not currently possible to declare an override VI as final, and someone's already made the request on the idea exchange.

[Kyle97330]

---

@_carl wrote:

I'd like to make this experience as user-friendly as possible.  Having other developers only see the two overrides I'd like them to override, as opposed to having a list of dozens of possible base-class overrides in the overrides drop-down would be an objectively better experience.  It reduces the risk of errors and minimizes ramp up for new developers.

In that case, I can suggest another alternative.  Instead of just telling developers to inherit from the class and override 2 and only 2 VIs, make a "template" descendant class instead.  It will be pre-setup with those two overrides already existing, already inheriting from the proper descendant, and you can put sample code with tons of comments in them inside those VIs as well.  Then when anyone wants to make a new class, they just open the template and do a "save as".

This is what I do for one of my classes that I have other people create inheritors for.  Each one has the 3 required overrides plus 3 more optional overrides pre-made with some "fill-in-the-blanks" type code, and anything else is up to them.  It's way easier than asking them to look at a list of 20+ overridable VIs and asking them to just pick one or two.

[wiebe@CARYA]

It's inheritance and polymorphism that make OO powerful. It's limitations that make OO practical. 

Private, Protected, Community scopes are limitations. They are not needed at all to make things possible. If anything, they prevent things from being possible. And that is very useful as a communication device.

Options that limit possibilities are a very effective means of communication. Other examples are 'must call parent', required connectors, containment and even password protection.

It's not that 'final' enables us to do something technical, 'final' is a limitation. It is a bit annoying that we have to live without it, as it will help communicate the intentions of the developer in a concise way. It's there in other languages for a good reason...

I don't think anybody is against having a 'final' option in LabVIEW, it's just that other things got prioritized. So, kodu those ideas, so it get priority!