Another problem with this.#myVar syntax is that it is not extensible to other access control definitions in future. For example "readonly" or "protected" etc.
On Fri, 12 Jan 2018 at 05:12 Claude Petit <[email protected]> wrote: > I'm with you Isiah... Sorry, but all that to avoid "this." is laziness, > has no sense and add complexity to the language. Use a modern editor > instead of VI and you'll have auto-completion of that "so difficult to > type" 4 letters word (this). > > -----Original Message----- > From: Isiah Meadows [mailto:[email protected]] > Sent: Thursday, January 11, 2018 5:26 PM > To: Naveen Chawla <[email protected]> > Cc: [email protected]; Augusto Moura <[email protected]>; > Brandon Andrews <[email protected]> > Subject: Re: Proposal: Alternative public, private, static syntax and > questions > > 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#issuecom > >>> > ment-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 > > > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
