Massive drawback of the # semantic: making a private variable public (a common transition when the usage of a class evolves) requires a lot more refactoring, since you have to remove every # for the variable across the class and replace it with `this`. Failing to do so in just 1 instance creates a bug. The same drawback applies for privatizing a public variable, in reverse.
Besides which as an instance variable I want to learn `this` as the access prefix. I don't want to have to learn 2 different access prefixes, one for public and one for private. Access control in code only has one real material advantage: simplifying the public interface of a class by hiding factors that have no use from outside it. This is not big enough of an advantage to introduce a new access prefix, which can lead to a plethora of bugs due to confusion and/or publicization/privatization transitions during the evolution of one's system. On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, <[email protected]> wrote: > Inline > > ----- > > Isiah Meadows > [email protected] > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews > <[email protected]> wrote: > > > > That is a very useful document. I guess I haven't opened the proposal in > a while. > > > > > > He puts a lot of stress on preserving encapsulation where as I was > planning on relying on a type system to optionally provide that feature. > That is given a dynamically typed variable accessing privates would > probably be allowed. (Statically typed variables would detect and not allow > that kind of like a more strict usage). > > The issue with leveraging static typing is that JS has never been a > statically typed language. Also, private fields are generally > something you shouldn't need static types to detect - even without the > sigil, it *is* in fact possible to require something like `private > foo` as a declaration and alter property lookup within classes to > check for local private names (for class instances) before public > ones. (Decided to create a GH issue out of this: > https://github.com/tc39/proposal-class-fields/issues/69) > > > I think the inheritance and using private names as keys are decent > arguments. That said I'm personally not against allowing inherited classes > access to their base class private members though. That is private acting > like protected in C++ I think is fine for ECMAScript. Am I alone in being > fine with that behavior? I'm kind of leaning toward: > https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883 > that syntax for a true private class scope variable. > > Note: not even Java allows subclasses to access superclasses' private > fields. > > > > > The key name conflict seems niche outside of key based data structures. > I wrote an ORM system before and just used a key called "internal" to hold > data in the past to get around a similar conflict. The # sounds like a > similar workaround when required but allows everything to not be hidden in > a nested object which is nice. > > > > Are "protected" class fields a thing in this discussion at all? Or is > the idea to use or implement a friend system later somehow? > > See https://github.com/tc39/proposal-decorators/issues/25. > > > > > > > With how I use Javascript currently, and the direction I want ECMAScript > to head - toward types - I don't particularly like the proposal or > necessarily support its goals toward creating an ideal encapsulation. (Also > I really dislike the syntax). > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
