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

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 `WeakMap`s 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 chatty, 
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.