Proposal: Alternative public, private, static syntax and questions

Naveen Chawla naveen.chwl at gmail.com
Fri Jan 12 11:15:45 UTC 2018


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 <petc at webmail.us> 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:isiahmeadows at gmail.com]
> Sent: Thursday, January 11, 2018 5:26 PM
> To: Naveen Chawla <naveen.chwl at gmail.com>
> Cc: es-discuss at mozilla.org; Augusto Moura <augusto.borgesm at gmail.com>;
> Brandon Andrews <warcraftthreeft at sbcglobal.net>
> 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
> me at isiahmeadows.com
>
> 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 <naveen.chwl at gmail.com>
> 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, <naveen.chwl at gmail.com>
> 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, <isiahmeadows at gmail.com>
> >> wrote:
> >>>
> >>> Inline
> >>>
> >>> -----
> >>>
> >>> Isiah Meadows
> >>> me at isiahmeadows.com
> >>>
> >>> 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
> >>> <warcraftthreeft at sbcglobal.net> 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
> >>> > es-discuss at mozilla.org
> >>> > https://mail.mozilla.org/listinfo/es-discuss
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180112/07f86e6d/attachment-0001.html>


More information about the es-discuss mailing list