- 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>
> 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