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

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Dec 31 12:25:21 PST 2012


On Dec 31, 2012, at 4:38 AM, Tom Van Cutsem wrote:

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

yes


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

But does  foo.[[Get]]("bar") ≠ undefined & foo.[[GetOwnProperty]]("bat") = undefined  ⇒ foo.[[getInheritance]]() ≠ null & foo.[[getInheritance]]().[[Get]]("bar") ≠ undefined

I hope not, as it would preclude all sorts of interesting "exotic" behavior.

The situation that dherman and I were discussing involved Typed Arrays.   While [[Get]]/[[Put]] need to access the array elements, it isn't clear that it makes sense to expose the elements via [[GetOwnProperty]].

This suggests a possible refinement of the definition of the term "own property":  a property that is accessible via [[GetOwnProperty]].


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

What? You expect me to me consistent?  :-)

I think we need to develop a better understanding (and ultimately specification) of  the essential invariants of the MOP (and not just those relating to high integrity objects).  Clearly an allowance for some inconsistency is probably necessary and useful. 

Allen

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


More information about the es-discuss mailing list