private name objects confusion

Dean Landolt dean at
Wed Jul 27 20:44:25 PDT 2011

On Wed, Jul 27, 2011 at 7:21 PM, David Herman <dherman at> wrote:

> > 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 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?

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.

> > 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.

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 :)

Another alternative for unique-but-public names is simply to have a unique
> string generator. It trivially maintains the invariants of getOPN and
> 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. But from a spec standpoint is
it a good idea to actively encourage the toStringing of getOPN keys? 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?

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list