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
