Brendan Eich (2013-07-31T05:56:55.000Z)
Mark S. Miller wrote:
> On Tue, Jul 30, 2013 at 9:19 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>     Mark Miller wrote:
>
>         On Tue, Jul 30, 2013 at 8:36 PM, Brendan Eich
>         <brendan at mozilla.com <mailto:brendan at mozilla.com>
>         <mailto:brendan at mozilla.com <mailto:brendan at mozilla.com>>> wrote:
>
>             Mark S. Miller wrote:
>
>                 Aside from this confinement issue, all other the
>         advantages
>                 that unique symbols have over unique-ish strings seem
>         minor to
>                 me. The biggest is default non-enumerability, when we're
>                 getting away (admittedly slowly) from enumerability being
>                 significant anyway. IMO, if the only advantages of unique
>                 symbols over unique-ish strings are these minor ones, then
>                 they don't pull their weight.
>
>                 However, I don't understand the confinement scenario
>         you have
>                 in mind. Can you give an example?
>
>
>             A friend field a la C++ "friend", e.g.:
>
>             module ... {
>               const friend = Symbol(); // however it's spelled
>               class A { ... }
>               class B { ... }
>             }
>
>             where fiend is used in the ... elisions but only to access
>             properties of objects known to be instanceof A or B.
>
>
>         Known how?
>
>
>     Lots of ways, e.g., |this| in bound methods,
>
>
> Only useful for instance-private instance variables, in which case you 
> may as well use lexically captured per-instance state.

No, "friend" is shared between two classes, no way to make a closure per 
instance extending over both constructors. Pretend the module above is 
an IIFE.

>     |this| after suitable instanceof tests with no mutable
>     [[Prototype]] (e.g., A and B  are sealed, manually in ES6 alas,
>     but still doable).
>
>
> Doesn't resist theft by proxy, since one can easily construct a proxy 
> that passes that instanceof test.

Ok, forget instanceof. With |this|-binding all around, what's the leak? 
More generally, are you arguing that leaks are hard to avoid, so we need 
private fields instead? That fits the relationship vs. unique symbol 
dichotomy.

/be
domenic at domenicdenicola.com (2013-08-02T20:40:11.535Z)
Mark S. Miller wrote:

> Only useful for instance-private instance variables, in which case you 
> may as well use lexically captured per-instance state.

No, "friend" is shared between two classes, no way to make a closure per 
instance extending over both constructors. Pretend the module above is 
an IIFE.

> Doesn't resist theft by proxy, since one can easily construct a proxy 
> that passes that instanceof test.

Ok, forget instanceof. With `this`-binding all around, what's the leak? 
More generally, are you arguing that leaks are hard to avoid, so we need 
private fields instead? That fits the relationship vs. unique symbol 
dichotomy.