domenic at domenicdenicola.com (2013-08-02T20:42:01.728Z)
On Tue, Jul 30, 2013 at 10:56 PM, Brendan Eich <brendan at mozilla.com> wrote: > 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. You're missing my point. My point is independent of whether there are two classes or one in the scope of your friend declaration. For simplicity let's say there's only class A. `this` binding only helps when a method is applied to its bound this, not to an argument. * It does not enable an instance of A to recognize that another instance of A is an A. * It does not avoid the storage cost of objects-as-closures, since you still need a function object per method per instance. > 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. If there is in fact no practical scenario for using unique symbols for privacy -- which is what we're exploring above -- then yes.
On Tue, Jul 30, 2013 at 10:56 PM, Brendan Eich <brendan at mozilla.com> wrote: > 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. You're missing my point. My point is independent of whether there are two classes or one in the scope of your friend declaration. For simplicity let's say there's only class A. |this| binding only helps when a method is applied to its bound this, not to an argument. * It does not enable an instance of A to recognize that another instance of A is an A. * It does not avoid the storage cost of objects-as-closures, since you still need a function object per method per instance. > > > |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. If there is in fact no practical scenario for using unique symbols for privacy -- which is what we're exploring above -- then yes. > > > /be > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/796990cc/attachment.html>