private name objects confusion

David Herman dherman at
Wed Jul 27 14:02:50 PDT 2011

> I've been exploring private name objects [1] and I'm a bit confused by a few things in the proposal, especially the Reflection example...

The page was out of date, sorry. I've updated the page to reflect the agreement we came to in the last face-to-face, which was that private names should not be reflected anywhere except to proxy traps. This leaks less information than what was on the wiki. In particular, now you can't figure out how many private names an object is carrying around.

> Should this statement return ["foo", fooName.public] or ["foo", fooName]? If the latter interpretation is correct, what advantage does a visible private name have over a plain old non-enumerable property?

Guaranteed uniqueness. For example, multiple separately developed libraries can monkey-patch the same shared prototype object with new unique names and they're guaranteed not to conflict.

I've separated this out on the wiki page as a remaining open issue. I'm not sure if we've come to consensus about this case. (One concern was that Object.getOwnPropertyNames() and no longer are guaranteed to produce strings, although this is mitigated by the toString() coercion of the name objects.)

> I also see no mention of what `str` should default to in Name.create, even though it's defined as optional and is quite significant as the name.public.toString return value. Is there something like a unique string value planned for this? At the very least the proposal should hint at what Name.create().public.toString() should return (assuming it's not undefined).

This hasn't been settled yet. IMO, I don't think it needs to be guaranteed to be unique. The uniqueness guarantee is about the *identity* of the object, and strings are forgeable, even if they're unique at the time they are created.

> My apologies if some of this has been discussed

Not at all; thanks for the feedback.


More information about the es-discuss mailing list