I'd have to disagree. There are ways to spec around this, and as long as you make explicit what you're inheriting, it's not as hard as you might think. -----
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 Fri, Jan 12, 2018 at 6:15 AM, Naveen Chawla <[email protected]> wrote: > 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
