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

Re: Should Exceptions be Errors in the ECMAScript bindings?

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Fri, 22 Jun 2012 17:46:59 -0700
Cc: Erik Arvidsson <arv@chromium.org>, Cameron McCormack <cam@mcc.id.au>, Travis Leithead <Travis.Leithead@microsoft.com>, public-script-coord@w3.org, Tom Van Cutsem <tomvc.be@gmail.com>
Message-Id: <9F71EB8C-6034-41E4-BAA2-78EB3ACEEE88@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>

On Jun 22, 2012, at 12:18 PM, Allen Wirfs-Brock wrote:

> 
> On Jun 22, 2012, at 9:50 AM, Erik Arvidsson wrote:
> 
>> On Fri, Jun 22, 2012 at 8:51 AM, Allen Wirfs-Brock
>> <allen@wirfs-brock.com> wrote:
>>> Given this direction, it probably isn't a good idea for WebIDL to be trying to standardize [[Class]] values and their usage as type tags.
>> 
>> Allen, maybe I am missing something. How do we ensure compatibility
>> with the existing web with the ES6 Object.prototype.toString behavior?
> 
> I guess the first question is whether there actually is a web compatibility issue here.  I believe that when we were first talking along these lines there was some significant differences among browsers in the names they were reporting. I'd have to to back in to check the details but perhaps particular differences were between pre-IE9 and other browsers.  
> 
> If this is an area of non-interoperability there would seem to be two ways to fix it.  Make it interoperable by  standardizing the DOM toString values (the WebIDL approach) or deprecate this use of {}.toString (the proposed ES6 approach).
> 
> If the Web IDL approach has gained too much traction then ES6 may need to provide a formal extension point for {}.toString that WebIDL can tie into.  In this case, I would propose a new  internal methods [[toStringName]] that is used to parameterize {}.toString.  It would be a replacement for [[Class]] that is only used for this purpose. It would not have any of the other ES internal nominal typing uses of [[Class].  If we do this, I believe [[toStringName]] would also have to be exposed as a Proxy handler.  Otherwise, Proxies could not be used to implemented fully compatible WebIDL objects.

Actually, I now remember that what I originally had planned for ES6's {}.toStirng is that it would fall back to looking for well known, string valued private named property to supply the class name. Assume, that we can refer to that private property name as Reflect.names.toStringName.  If you (or WebIDL) want DOMException objects to {}.toString as "[object DOMException]" you would define:
   Object.defineProperty(DOMException.prototype,Reflect.names.toStringName, {value: "DOMException"});

(we haven't decided yet how these well known private name will actually be exposed so Reflect.names.toStringName is just a place holder).

This allows ES code to extend {}.toString without resorting to the use of a Proxy as would be required with the [[toStringNamne]] approach.  Either approach is feasible but the private name is more flexible and less intrusive upon the overall ES6 design.

Sorry I was slow in pulling this all together.  I've had some distractions the last couple days.

Allen








> 
> Allen
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> -- 
>> erik
>> 
> 
> 
> 
Received on Saturday, 23 June 2012 00:47:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:06 UTC