Proposal: Alternative public, private, static syntax and questions

Isiah Meadows isiahmeadows at gmail.com
Thu Jan 11 22:26:17 UTC 2018


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#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
>>> > 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


More information about the es-discuss mailing list