Proposal: Alternative public, private, static syntax and questions

Isiah Meadows isiahmeadows at gmail.com
Thu Jan 11 19:52:06 UTC 2018


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


More information about the es-discuss mailing list