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

[WebIDL] Eliminating [ImplicitThis] in favor of [Global]

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 23 Sep 2013 12:28:41 -0400
Message-ID: <52406C39.5020501@mit.edu>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
For background reading, see 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18547

I would like to propose the following:

1)  We have a [Global] annotation for the primary interface for the
     global object (I think we've more or less agreed on this already).
2)  All WebIDL operations/getters/setters on any prototype that lives
     on the canonical prototype chain of the global object get the
     ImplicitThis behavior: null/undefined are treated as "the" global
     (I'll start a separate thread on what that means).

Note that my item 2 is somewhat different in theory from giving all 
inherited and consequential interfaces of the [Global] the ImplicitThis 
behavior.  In particular, consider this IDL:

   [Global]
   interface Window {};
   interface B {};
   interface C {
     void doSomething();
   };
   Window implements C;
   B implements C;

In my proposal, B.prototype.doSomething.call(undefined) will simply 
throw, while A.prototype.doSomething.call(undefined) will be equivalent 
to window.doSomething() (assuming the global is a Window).

In practice, this would also be true for 
B.prototype.doSomething.call(window) vs 
A.prototype.doSomething.call(window), so the above proposal is actually 
black-box equivalent to making all WebIDL methods ImplicitThis, except 
possibly for error-reporting purposes.  Not like any UA has decent error 
reporting here...

Thoughts?

I can maybe see arguments about not doing this in workers, but I'd like 
to see some compat data from someone making such an argument.  In a 
Window, browsers definitely coerce bareword gets/sets/methods to work on 
the window itself as thisobj, so this will be needed for compat.

-Boris
Received on Monday, 23 September 2013 16:29:10 UTC

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