private name objects confusion

David Herman dherman at mozilla.com
Thu Jul 28 00:53:31 PDT 2011


> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110728/b2265ce4/attachment.html>


More information about the es-discuss mailing list