Language Specification: Underscore-prefix encapulation boundary

[dkearns]

The underscore prefix is used to declare what are referred to in the help as "private" features of a class. In the case of instance variables and methods these actually have what is commonly referred to as "protected" access, i.e., subclasses also have access.

This is unusual and I'd expect that most programmers with a background in any mainstream languages from the last thirty years would reasonably expect these to be class private. While a case could be made for an object-based rather than class-based view of encapsulation, and one I probably favour, it's far from the norm.

Being unable to export a class with features inaccessible to derived classes seems like an awkward limitation given standard OO modelling practices (for better or worse).

The help is also not very clear on this topic.

[errael]

I don't remember which issue/PR/discussion this came up in before and there's not really any reason to find it (I'm content to believe that I could find it if I tried). I did rather enjoy the "it's a feature"/"that's what they all say" exchange.

So you're saying

1. Vim's access model is object based with no class/subclass considerations; (its a binary choice, you're in the object or you're not.
2. I guess there is no (2). The implication of (1) is that any subclass has full access to anything in the object.
3. The common feature "export a class with features inaccessible to derived classes" is not available.

It is true that private static members can not be accessed by derived classes.

Is something I'd like to do prevented by this access model? Of course not, programmers can do anything. But how much extra work is needed to do something the more common model can easily do? Worst case, I can do something like, in a single file

1. C extends B extends A
2. export B
3. put the hidden stuff in C, which is accessed by A through overridden functions

Not pretty. The question of whether or not I'd need to do that is hard to say.

I wonder what it would take, if the current model is released in vim9.1, to add the ability to "export a class with features inaccessible to derived classes". How about

• _ means protected
• add a new keyword: private

does that work such that class (not object) privacy is available and old code continues to work?

[vim-ml]

I don't remember which issue/PR/discussion this came up in before and there's not really any reason to find it (I'm content to believe that I could find it if I tried).

#12932 // if you're willing or still cost OK to change, please perhaps just think that 'default' one // note that term 'public' there actually should be meant 'protect' which i said at #11827 // public still was public

…

-- shane.xb.qian

[dkearns]

I don't remember which issue/PR/discussion this came up in before and there's not really any reason to find it (I'm content to believe that I could find it if I tried). I did rather enjoy the "it's a feature"/"that's what they all say" exchange.

I'm not quite sure what you're getting at but it was #13195, which is related but they can be discussed separately. Fixing this issue in isolation would actually make that issue worse. Access controls seem a bit of mess to me but I think the export and class boundaries are the only two of real interest if we're simplifying as much as possible.

I've found the Zimbu spec very illuminating. In my opinion, a lot of the rough edges in Vim9 script are the result of using a subset of its features that don't work all that well in isolation.

So you're saying

1. Vim's access model is object based with no class/subclass considerations; (its a binary choice, you're in the object or you're not.

2. I guess there is no (2). The implication of (1) is that any subclass has full access to anything in the object.

Essentially, but I'm derailing this with half-baked conceptual musings as usual. :) The bottom line is that "private" as I'd argue it's generally understood isn't the same as available here. There's pragmatic and theoretical reasons that "protected" is often discouraged but I think standard practice is good enough guidance.

I can think of few modern languages that have done away with "protected" access but Dart, for example, later added some support for this with an annotation for the analyser.

It is true that private static members can not be accessed by derived classes.

I don't think that matters.

Not pretty. The question of whether or not I'd need to do that is hard to say.

I might be misunderstanding you but are you saying you've never used "private" with intent in Java? You escaped indoctrination into the OOP cult and its love of private data? :)

I wonder what it would take, if the current model is released in vim9.1, to add the ability to "export a class with features inaccessible to derived classes". How about

* `_` means protected

* add a new keyword: `private`

does that work?

I find it hard to believe anyone would design a language with this mix of keywords and sigils. :)

Making _ mean private data and protected behaviour might be reasonable but "object variables" behave like properties in various places.

I think just making _ mean class-private would be better.

If no one "has anything to hide" (always a red flag) then the help should at least be reworded so that there's less confusion.

[Shane-XB-Qian]

I don't remember which issue/PR/discussion this came up in before and there's not really any reason to find it (I'm content to believe that I could find it if I tried). I did rather enjoy the "it's a feature"/"that's what they all say" exchange.

I'm not quite sure what you're getting at but it was #13195,

i think it was #12932 which i said above comment, a loooong "discussion".

I find it hard to believe anyone would design a language with this mix of keywords and sigils. :)

😄 even you'd like to change, it had been too late,
and maybe there were some advantage of such, so unless you found something really hard to play, then perhaps let it be.

[errael]

[snip references about script access into classes and Zimbu]

So you're saying

1. Vim's access model is object based with no class/subclass considerations; (its a binary choice, you're in the object or you're not.

2. I guess there is no (2). The implication of (1) is that any subclass has full access to anything in the object.

[I edited the original post to add (3)]

3. The common feature "export a class with features inaccessible to derived classes" is not available.

Essentially, but I'm derailing this with half-baked conceptual musings as usual. :) The bottom line is that "private" as I'd argue it's generally understood isn't the same as available here.

Yeah, what does the _ access modifier mean? Vim uses _ where other languages use protected; Vim does not have private. Calling it private in the docs is very confusing.

I might be misunderstanding you but are you saying you've never used "private" with intent in Java? You escaped indoctrination into the OOP cult and its love of private data? :)

I'm not saying that at all, my default is private. IMHO, distrust and paranoia well serve the programmer. But it's possible that in a controlled programmer environment...

I wonder what it would take, if the current model is released in vim9.1, to add the ability to "export a class with features inaccessible to derived classes". How about

* `_` means protected

* add a new keyword: `private`
  
does that work?

I find it hard to believe anyone would design a language with this mix of keywords and sigils. :)

Yes. But I seem willing to accept extraordinary measures to move forward from where we are.

Making _ mean private data and protected behaviour might be reasonable but "object variables" behave like properties in various places.

I'm confused by that statement. I meant that in the current language _ means protected, and it should be documented as such; there currently is no private. A private modifier could be added with the traditional meaning. (and I might be misunderstanding something)

I think just making _ mean class-private would be better.

With no protected? I wouldn't like that.

If no one "has anything to hide" (always a red flag) then the help should at least be reworded so that there's less confusion.

Totally agree with that.

I like protected, in spite of it's theoretical issues, and inheritance. I also like composition. Each is useful and can be overused. The screwy _/private I mention is just a way that private could be added after vim9.1 is release. The key for that being at all possible, without complete chaos, would be to document _ for what it really is, "protected", and not call it "private".

One reason to defer class private is that perhaps the access model could be extend with #13195 at the same time.