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
Tue Jan 1 03:12:39 PST 2013
2012/12/31 Allen Wirfs-Brock <allen at wirfs-brock.com>
> On Dec 31, 2012, at 4:38 AM, Tom Van Cutsem wrote:
> 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"
In working out the proxy the invariant checks, Mark and I explicitly
decided not to consider invariants that involve the inheritance chain, such
as the invariant stated above. So an inconsistency between [[Get]] vs.
[[GetOwnProperty]]+[[GetInheritance]] is tolerated by Proxies, and is
probably also tolerable for other exotics (such as toString for Symbols and
array elements for TypedArrays).
> 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]].
Yes, and this corresponds to the way the proxy invariants check whether a
property is "own" on the target.
(there's also [[HasOwnProperty]] answering "true", but in principle,
[[GetOwnProperty]] should be consistent with [[HasOwnProperty]])
> 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.
I think we're already mostly there. I think the list of invariants enforced
by proxies is precisely the list of essential invariants of the MOP.
As you stated earlier, an inconsistency between "derived" operations such
as [[Get]] and [[HasProperty]] is not really harmful. That said, we
shouldn't underestimate these. I think at least some of the frustration
against DOM objects derives from such "minor" inconsistencies.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss