> 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
