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 some options.
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@tty, requires too much boilerplate. This was among the reasons given when we deferred it.
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.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
