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

RE: Question about implements statements

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 19 Jun 2012 16:53:04 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B383839C786@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> Again, my question is this, and I will try to reduce confusion by using methods
> instead of attributes.  Given this IDL:
> 
>    [NoInterfaceObject]
>    interface Mixin {
>      void doSomething();
>    };
> 
>    [Constructor=()]
>    interface X {};
>    X implements Mixin;
> 
>    [Constructor=()]
>    interface Y {};
>    Y implements Mixin;
> 
> and this script:
> 
>    x = new X();
>    y = new Y();
>    x.doSomething.call(y);
> 
> should the call throw or should it do the same thing as y.doSomething()?

It should act exactly as if y.doSomething() had been called--in fact how could
"doSomething" know any different? With "call", "apply", etc., function objects
 (and getter/setters) must be implemented such that they determine their behavior
based on the "this" caller and param set they receive.

In IE8 and previous versions, our DOM implementation had the notion of an 
internal-bound "this" object (and didn't support call/apply). Thus the following 
would work:
var w = document.write;
w();
First of all, because "w" was a host object and not a native function, when you 
invoked w() it "knew" internally that it should operate on the document object as
it's "this" value. However, when we implemented a full WebIDL binding in IE9, many
websites that used this behavior encountered script errors because in actuality the 
call to invoke w() will pass the global/window object as the "this" value unless you 
first bind the document to the function:
var w = document.write.bind(document);

My point is that the implementation of "write" must be able to be invoked from any 
object, and the call-params validation for the function must happen internal to the 
function code itself.

> For that matter, should x.doSomething == y.doSomething test true or false?

It should be false. The notion of getting a "copy of each property" means a new 
unique instance. == and === perform same-instance comparisons and the copies 
(while having the same name) are not the same instance in the type system. 
Implementations, however, will likely process these calls using one internal 
implementation of the code for those multiple entry-points.

> Even _that_ is not obvious from the spec, now that I read it again.  I had initially
> read it as testing false, but now I'm not quite sure.  What exactly does it mean to
> have "a copy of each property"?
> What gets copied?
> 
> -Boris
Received on Tuesday, 19 June 2012 16:53:40 UTC

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