Adapt Method VI Icon to access scope

[GJMABerends]

Definition of the problem:

To find the scope of an method in code quickly there are two options:

1. Either place it in another VI or in a child class method, if it breaks you know the scope. 
2. Look into the project explorer and find it there.

It would be nice if we could avoid the above two methods of finding out the scope.

Current solutions:

Of course we can add text in the icon (limited space) or rename the method so it has the private/public/community name in the method (long file names and a loth of work when changing the access scope) and even add descriptions for the scope which requires the context help window to be open.

But there is a more elegant solution: In the project explorer there is an way to find out the scope of the Methods in a single glance by the glyphs used on the icons.

So incorporating this in the Icons of the methods makes sense. Even better there are already a glyphs of the protected and private methods. 

 

Proposed Idea:

Changing the access scope into private/protected/public or community automatically add an layer with the corresponding glyph of the access scope. This makes it clear what the scope of the methods are and thus avoiding breaking the code/using long names/writing it in the icon or place it in the description. Automating this also removes a loth of extra clicks to get the same result.

[AristosQueue (NI)]

You are free to badge your icons how you choose. The idea of this kind of badging has been discussed with customers many times, both here in the forums and elsewhere in various customer contexts, and rejected every time. It has been discussed for access scope, for reentrancy, for inlining, for dynamic dispatching... etc. The decision has always been the same: LV should not cover any portion of the user icon with custom glyphs beyond the coercion dot that already exists. Adding such information around the node (i.e. the Express VI halo or similar) has likewise been rejected as it adds to the overall size of the node.

Personally, I have a theory that such annotations would be more unhelpful than helpful... they would be unnecessary noise the vast majority of the time. I have never tested this theory, but I note that call sites of functions are not typically annotated with access scope in other programming languages, not within the user source nor by highlighting of the IDEs. I don't really know why this is, but it seems that other programming environments have come to the same conclusion: annotations of scope don't belong on the call site. If you need to know the scope, go to the class definition... in LV's case, the project tree.

In LabVIEW NXG, there are plans to make classes more explorable, and a temporary layer for turning on such annotations momentarily has been discussed. It seems likely that at some point, something like that will happen in NXG, but it will be separate from the icon itself.

[Darren]

Declined for reasons listed by AristosQueue in the comments thread