> 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 for...in 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. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
