Proposal: Alternative public, private, static syntax and questions

Logan Smyth loganfsmyth at gmail.com
Thu Jan 11 23:20:39 UTC 2018


The `#foo` shorthand part of the proposal was removed: https://github.com/
tc39/proposal-class-fields/issues/21

On Thu, Jan 11, 2018 at 2:26 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180111/eced7cf5/attachment-0001.html>


More information about the es-discuss mailing list