The `#foo` shorthand part of the proposal was removed: https://github.com/ tc39/proposal-class-fields/issues/21
On Thu, Jan 11, 2018 at 2:26 PM, Isiah Meadows <[email protected]> wrote: > The proposal does a very poor job of explaining this, but `#foo` is a > shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo: > foo}`. That kind of thing has precedent in other languages: > CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's > not private), and Ruby uses `@foo` as a shorthand for `self.foo` > (which is private by default). Most traditional strongly typed OO > languages just let you omit `this` and just reference the property as > if it were a variable in scope, without the sigil, and Ruby does as > well for methods. > > It saves 5 characters in the most common case, accessing private > properties of the current instance. > ----- > > 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 4:26 PM, Naveen Chawla <[email protected]> > wrote: > > I hadn't read the proposal properly, but the thrust of my point is the > same, > > read remove/add `#` instead of "replace with this" > > > > > > On Fri, 12 Jan 2018, 2:47 am Naveen Chawla, <[email protected]> > wrote: > >> > >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
