Hiding variables marked with @access JSDOC.

[softwareantics]

Hiding variables marked with @access JSDOC.

[adam-coster]

By "hide" do you mean keep them out of autocomplete (would be easy)? Or, for the case of private variables, only allow them to autocomplete in the scope in which they are defined (a little difficult for basic functionality, really difficult for full functionality)?

Or should they be in autocomplete but show a warning when used?

If such variables do get used without autocomplete, would that be flagged as an error?

[softwareantics]

I think a good solution to start would be to hide variables from autocomplete that are marked as private via JSDocs or maybe prefixed with an underscore.

Adapting later on to provide more intelligent autocomplete would be a good idea.

Open to suggestions :)

[adam-coster]

This is tricky since I think it's pretty rare that you want something to be universally excluded from autocomplete. We probably need to break it down by case to figure out what kind of behavior would be useful.

Cases that come to mind:

• You may have functions defined in scripts that are only useful within that script, so you wouldn't want to see them everywhere else. But in that case it's probably better to refactor so that those things aren't global (e.g. as statics inside of other functions or constructors somewhere).
• For libraries, you may have variables that you want to see while working on the library, but not when the library is used in the context of another project. But you probably want autocompletes for some of the stuff in the library. I'm not sure how you'd get the subset you want, especially since you'd be dependent on the library author to annotate things properly (or to follow a naming convention).
• self variables in objects that you only want to see when you're in the object's code (rather than when you reference the object in other files). E.g. if I've got an object obj_a with an internal function _on_step(), I'd want to be able to see that function elsewhere in the object code but not when I'm dotting into an instance of that object. That would be pretty straight-forward to implement -- we'd just skip _on_step() unless the current file is one of obj_a's event files. But if I do decide to reference that function somewhere else, I'd probably want a warning instead of an error.
• self variables in struct literals and constructors are similar to objects, and I can see wanting to limit their visibility to within the literal's definition or the constructor body. That's a little trickier than just checking what file we're in, but probably doable. As with objects, I imagine we'd want to see a warning when these are used outside of their "private" scope, but still have them work there.
• Local variable already have limited visibility, so I don't see a use-case for hidden local variables.

At least for the cases I can think of, I can see a case for Typescript-style protected variables that wouldn't bee too hard to implement. private (also not accessible to constructors/objects inheriting from the parent with that variable) may be doable but definitely adds a layer of complexity.

I can see starting with implementing a @protected JSDoc for self variables that works as described above. Having a configuration option to allow specifying a prefix/pattern to treat matching variables as protected even without the JSDoc wouldn't be a big deal once the functionality was in place.

Does that cover the kind of thing you're imagining? Do you have any specific cases of things you want to hide? If so, where do you want them visible versus invisible, and why?