On Jul 12, 2011, at 7:43 AM, Brendan Eich wrote: > On the other hand, there's no free lunch for private names having a new > typeof type: "name". They cannot be strings, so the VM's property lookup and > identifier-handling code paths all need a wider type. True, they *could* be > UUIDs in strings that have a tag bit set to prevent forgery, but that's not a > likely implementation. > > So given that id types and lookup code paths have to change anyway, this > seems more of a wash than you suggest. Not a total wash, but not a clear with > for new typeof-type "name".
Er, "not a clear win...." Another point about implementations: any that perform at all well already use a sum type for their internal property id representation, to accomodate int or uint *or* string. Adding another arm to that discriminated union is not a huge amount of work, in our experience. For JavaScriptCore, Oliver has argued that internal to the engine, keeping id uncoerced as an arbitrary value, until late or "deep" in the layering, is not troublesome and could allow better true array or vector indexing semantics, e.g. via proxies. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
