private name objects confusion

Dean Landolt dean at deanlandolt.com
Wed Jul 27 15:51:48 PDT 2011


On Wed, Jul 27, 2011 at 5:02 PM, David Herman <dherman at mozilla.com> wrote:

> > I've been exploring private name objects [1] and I'm a bit confused by a
> few things in the proposal, especially the Reflection example...
>
> The page was out of date, sorry. I've updated the page to reflect the
> agreement we came to in the last face-to-face, which was that private names
> should not be reflected anywhere except to proxy traps. This leaks less
> information than what was on the wiki. In particular, now you can't figure
> out how many private names an object is carrying around.
>

Perfect! This is exactly what I was hoping for.

[snip]

I've separated this out on the wiki page as a remaining open issue. I'm not
> sure if we've come to consensus about this case. (One concern was that
> Object.getOwnPropertyNames() and for...in no longer are guaranteed to
> produce strings, although this is mitigated by the toString() coercion of
> the name objects.)
>
> > I also see no mention of what `str` should default to in Name.create,
> even though it's defined as optional and is quite significant as the
> name.public.toString return value. Is there something like a unique string
> value planned for this? At the very least the proposal should hint at what
> Name.create().public.toString() should return (assuming it's not undefined).
>
> This hasn't been settled yet. IMO, I don't think it needs to be guaranteed
> to be unique. The uniqueness guarantee is about the *identity* of the
> object, and strings are forgeable, even if they're unique at the time they
> are created.
>


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.

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

Ah well, this is great stuff. Thanks again, Dave...

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


More information about the es-discuss mailing list