> Yep. Sorry, editing snafu -- I'd started to call it a non-issue when it > occurred to me that proxy authors would still have to know not to string > coerce keys. No big deal -- proxy authors should know better than to rely on > es5 invariants.
Agreed. > Throw at the point where a unique name from a getOPN array is coerced to a > string. AFAICT this will always indicate a logic bug. One way to enforce this > would be to have getOPN (and enumerate?) hand out public objects with special > toStrings that throw. Meh. That's why I said there's "sane" way :) Yikes. :) > > 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. > > Yes, this is precisely what I meant when I said a unique string could be > used. But again, I wonder if worth it. If a producer of unique name objects > can provide the internal string it's trivial to generate UUIDs (or any other > type of unique string) should they so choose. Right, this is already something you can express in the language. I sense YAGNI. > But from a spec standpoint is it a good idea to actively encourage the > toStringing of getOPN keys? What I meant was that we could not provide the visibility flag -- i.e., not have a notion of "unique names" at all -- but simply provide a makeUUID() function that produces a string which can be used directly as a property name. > A bigger problem: what happens when you have two unique name objects where > both have a "foo" internal string and you toString the result of getOPN? Bad > things, right? Right. This issue is why I suggested using UUID strings instead. It wouldn't be possible to have two properties with different unique names that produce the same UUID result of toString(). > Another alternative would be to explicitly disallow custom internal strings > for unique name objects, and give them a consistent toString behavior (e.g. > always generate unique strings). But this smells too, partly for the reasons > you pointed out, and also because the semantics of the two name types start > to diverge. Agreed. > So I wonder: what does this particular reflection buy you that you can't just > as easily attain by explicitly exposing your "visible" private name objects? The only thing is that you can't introspect on them conveniently. If you have access to a private name, it'd be nice to have a simple way of saying "give me all of the names, including the private names I know about." But I don't see a simple way of doing that other than something like a variant of getOPN: Object.getOwnPropertyNames(o, p) : function(Object, WeakMap<name,any>?) -> [string | name] This version would produce an array of all property names including any private names that are in the given table. (This is technically a conservative extension of the existing ES5 getOPN but it could alternatively be provided as a different function.) Again, this would be implementable without providing it as a core API, so I'm not sure if it's worth it. Standardizing on this use of a map seems like it might be premature; you might want any number of different ways of representing "these are the private names I know about." Dave
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss