W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Interface prototype objects and ES6 @@toStringTag

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 13 May 2013 15:24:58 -0700
Cc: public-script-coord@w3.org
Message-Id: <368020D3-8829-4870-AFC5-FF8B66D9FB4C@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On May 13, 2013, at 2:47 PM, Boris Zbarsky wrote:

> On 5/13/13 4:50 PM, Erik Arvidsson wrote:
>> The way that WebIDL require Object.prototype.toString to return "[object
>> TypePrototype]" for the interface prototype object and "[object Type]"
>> for the instances seems to imply that every instance needs to have an
>> own @@toStringTag.
> 
> Just to check my understanding, is this because there is no concept of an accessor for a symbol object get, so that Get(O, @@toStringTag) cannot perform introspection of O?  At first glance it seems like nothing prevents there being an accessor invoked as a result of Get(), though I'm a little confused about the code that does this Get(): it seems to expect back something with a .[[value]] but as far as I can tell Get() returns a value, not a descriptor...

That's just dealing with ES internal Completion records which is how exceptions and other control flow changes are modeled within the ES pseudo code.  .[[Value]] is the actual value returned from a successful [[Get]] property access.  

The [[Get]] access could be triggering an accessor function that threw or the object that is accessed might be a Proxy with [[Get]] handler that throws.  Legacy Object.prototype.toString never would throw so I figured that was a good property to preserve because Object.prototype.toString is sort of a last resort debugging output alternative.  I've written the spec. such that it eats such [[Get]] related exceptions  produces [object ???] as its output.  This last point is probably still open for discussion if enough people think that O.p.toString should be allowed to fail with an exception.

Allen
Received on Monday, 13 May 2013 22:25:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC