Yeah, sorry half-cocked idea, badly described: Generate a unique private property name as a pair (Class ID, property name).
If you rely on object IDs, you don’t have to think about that at all, only if you want to reproduce a private name somewhere else (say, in a unit test) *without* passing the name object around. On Oct 2, 2011, at 19:17 , Brendan Eich wrote: > On Oct 2, 2011, at 5:54 PM, Axel Rauschmayer wrote: > >>> Still, we moved private name objects ahead, and rightly so, without adding >>> syntax for them. >> >> That makes sense, as it doesn’t preclude sugar in the future. One thing to >> consider: Do private names need to be globally unique or is unique-per-class >> enough? The former enables many intriguing other applications, but it might >> preclude moving to a nicer syntax later on. > > They are objects with unique identity. Objects have identity, primitive types > do not. You can forge a string. You can't forge an object. It's a capability. > > If you mean to suggest two classes C and D, each with a private name P, where > C's P === D's P, that is a very bad idea. It's a capability leak, a channel > for communicating, attacking, and subverting D from C. > > /be -- Dr. Axel Rauschmayer [email protected] twitter.com/rauschma home: rauschma.de blog: 2ality.com _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
