Mark S. Miller wrote:
On Tue, Jul 30, 2013 at 9:19 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Mark Miller wrote:
On Tue, Jul 30, 2013 at 8:36 PM, Brendan Eich
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
