using Private name objects for declarative property definition.

Brendan Eich brendan at
Tue Jul 12 08:34:50 PDT 2011

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.


More information about the es-discuss mailing list