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

Re: Should Exceptions be Errors in the ECMAScript bindings?

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 23 Jun 2012 12:13:10 +1000
Message-ID: <4FE52636.7050002@mcc.id.au>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
CC: Erik Arvidsson <arv@chromium.org>, Travis Leithead <Travis.Leithead@microsoft.com>, public-script-coord@w3.org, Tom Van Cutsem <tomvc.be@gmail.com>
Allen Wirfs-Brock:
> 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).

As a way to have Web IDL platform objects return the right values when 
passed to {}.toString, that sounds fine to me.  For the moment, though, 
the Web IDL spec is targetting ES5.1.  Maybe we should have the v2 
document (now that I've branched it off) target ES6?

(As a reminder: what the spec currently says is not that [[Class]] has 
some custom values, but that after an ECMAScript environment is created, 
Object.prototype.toString is replaced with a version that does return 
the right values.  This AFAICT does not violate the ES spec, but it is a 
bit of a hack!)
Received on Saturday, 23 June 2012 02:14:03 UTC

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