Symbol toString behavior (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

Tom Van Cutsem tomvc.be at gmail.com
Mon Dec 31 04:38:06 PST 2012


2012/12/31 Allen Wirfs-Brock <allen at wirfs-brock.com>

> responses for chapter 8, except for 8.5 which will get its own message.
>
> On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
>  > 8.4.4 Exotic Symbol Objects
> > Typo: "A{n} Symbol object is an exotic object…"
> > "Exotic String objects have {the} a..."
> fixed
> >
> > In the introduction, it's mentioned that "Symbol exotic objects are
> unique in that they are always immutable and never observably reference any
> other object."
> >
> > Yet, as currently specified, evaluating aSymbol.toString yields a
> reference to the global Object.prototype.toString function (which is
> mutable by default).
> I agree, that the statement does not quit match the apparent behavior.
>  Yet, the definition of [[GetP]] for Symbols makes it clear that the symbol
> itself does not reference the toString method and instead it is using the
> toString intrinsic of the Realm associated with the execution context that
> did the [[GetP]] access.
>
> I'll think about how to express the key idea (symbols directly carry no
> object references) while still supporting toString
>
> >
> > Shouldn't aSymbol.toString just be undefined?
> >
> > I notice that Object.prototype.toString special-cases Symbols anyway, so
> Object.prototype.toString.call(aSymbol) continues to work fine.
> >
>
> I think, for debugging, people will prefer to obj.toString() to yield
> "[object Symbol]" rather than throwing when obj happens to be a symbol.
>

Ok, so if I understand correctly, security issues are mitigated because
aSymbol.toString always evaluates to the realm-local
Object.prototype.toString. In a sandboxed environment where this built-in
was frozen, aSymbol.toString will also be frozen.


> > In case aSymbol.toString should continue to return
> Object.prototype.toString, I would advise to modify [[HasProperty]] for
> Symbols to answer 'true' for the string "toString", and [[Delete]] to
> answer 'false', so that [[Get]],[[HasProperty]] and [[Delete]] remain
> internally consistent.
>
> I'm not so sure.  DHerman and I had a recent conversation about a related
> matter, and its not clear that it always makes sense to make [[GetP]] and
> [[GetOwnProperty]] consistent.  In this case, note that [[GetOwnProperty]]
> would be required to report that toString was writable, because its value
> observably changes based upon the Realm from which it is accessed.
>

It would not be inconsistent for [[GetOwnProperty]]("toString") to return
undefined. This simply signals to clients that "toString" is not an "own"
property of the Symbol, which is fine.

In this case, it may be better to have this be a little hack that supports
> debugging and not worry about all the other small inconsistencies that are
> not really guaranteed invariants, regardless.
>

Sure, I won't lose sleep over this. Although I think it's amusing that you
yourself are passionate about end-user proxy handlers consistently
overriding interdependent traps, while this part of the spec
ignores precisely that guideline ;-)

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121231/eb08d545/attachment.html>


More information about the es-discuss mailing list