On Dec 31, 2012, at 4:38 AM, Tom Van Cutsem wrote:
> 2012/12/31 Allen Wirfs-Brock <al...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
