- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Fri, 22 Jun 2012 12:18:37 -0700
- To: Erik Arvidsson <arv@chromium.org>
- Cc: Cameron McCormack <cam@mcc.id.au>, Travis Leithead <Travis.Leithead@microsoft.com>, public-script-coord@w3.org, Tom Van Cutsem <tomvc.be@gmail.com>
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.
Allen
>
> --
> erik
>
Received on Friday, 22 June 2012 19:19:14 UTC