class-private syntax in ES6 (was: ES6, ES7, ES8 and beyond. A Proposed Roadmap.)
brendan at mozilla.com
Mon Apr 29 09:09:44 PDT 2013
Rick Waldron wrote:
> Mark Miller and I had an offline discussion that clarified for me that
> the example using a symbol as a property key would allow the value to
> be discovered via ES6's Object.getOwnPropertyKeys() which returns the
> result of the internal [[OwnPropertyKeys]] method. The mistake I had
> made was assuming that where [[OwnPropertyKeys]] mentions "private
> Symbol" that it actually just meant the thing one Symbol that is just
> a Symbol—which is incorrect.
Sorry, I didn't follow the last sentence -- but the first confused me
too. We haven't finished ES6 yet, and Object.getOwnPropertyKeys is new.
We can decide what it reveals, e.g., whether it censors private symbols.
But only if we add private symbols as a variation on symbols.
The relationships work is in my view about enabling private *syntax* to
map to something that could be implemented by GC-optimized WeakMaps or
(essentially) private symbols. That seems like a win, since we're
designing for users first, not implementors (and implementors can
certainly cope, lots of options).
Users want class-private (and module-private?) syntax.
What proxies do is an open issue, but the relationships strawman lists
> I've always been an @-name supporter and have had a pending
> revisitation agenda item for the last two meetings, deferred in favor
> of the bigger fish we had to fry ;)
Some of us on TC39 don't like the @-name proposal, it's too ch at tty,
requires too much boilerplate. This was among the reasons given when we
The relationships' strawman infix-@ operator, combined with
uncontroversial private declaration syntax (including, I believe this is
uncontroversial too, constructor formal parameter prefixing with
'private' to declare and initialize) looks to be both more concise and
sufficient for the use-cases we've aspired to serve.
More information about the es-discuss