> Understood WRT the forgeability of strings -- I was more concerned with the > potential hazard of toStringing the values of an own-names array, only to > find out you have several keys with the string value "undefined". Sure you're > doing it wrong, but string keys are an es5 invariant -- it's bound to happen, > as you hinted at in your reply.
Yeah, this has come up several times in discussions. It's currently an invariant that for...in and getOPN produce a sequence of strings with no duplicates (though not in fully specified order), and exposing name objects to these operations would break that invariant. > But now that you've clarified the reflection semantics it's clear that this > is not much of an non-issue for non-reflective "private" names, ITYM "not much of an issue", right? > just another note for proxy authors. Of course, if the visibility flag > becomes harmonious (and I really hope it does!) it's still a bit of a problem > for these "unique" names. There's no need for unforgeability here so a unique > string could be used, but it's probably too much magical and too little help > -- if unintentionally used (the result of an own-names string coercion) it > papers over a deeper semantic bug. Better would be to throw, but there's no > sane way to do that. Throw where, exactly? I don't quite follow you. Another alternative for unique-but-public names is simply to have a unique string generator. It trivially maintains the invariants of getOPN and for...in while still having the same user experience for getting and setting. The downsides are that the string will probably be ugly and unpleasant for debugging, and that there's no efficient way to ensure that the string generated won't be one that's *never* been observed by the program so far. You'd probably have to use UUIDs, which are ugly. > Ah well, this is great stuff. Thanks again, Dave... Glad to hear it! Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
