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

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.

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


More information about the es-discuss mailing list