- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 19 Jun 2012 14:29:50 -0400
- To: Travis Leithead <travis.leithead@microsoft.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 6/19/12 12:53 PM, Travis Leithead wrote: > It should act exactly as if y.doSomething() had been called--in fact how could > "doSomething" know any different? That's where the question whether x.doSomething == y.doSomething is important. Gecko's current implementation of "X implements Y" basically copies methods from X to Y in the data structure representing the WebIDL. The actual generated code for those methods then treats them as methods declared directly on X. So in my example, we would have x.doSomething != y.doSomething, and they would be functions that expect totally different this objects: the former would expect an instance of X while the latter would expect an instance of Y. > 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. Yes, but the question is WHAT that behavior should be when "implements" is used. > 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. Yes, yes. That point is, with all due respect, obvious in the WebIDL context, and I already said that we agree on it, so I'm not sure why you keep bringing it up. What's not obvious is _what_ this internal call-params validation should be for the specific case of "implements". >> For that matter, should x.doSomething == y.doSomething test true or false? > > It should be false. Why? I would like it to be false too, but the spec does not make that clear. > The notion of getting a "copy of each property" means a new > unique instance. Where does the spec say that? > == and === perform same-instance comparisons But on what? If, say, Mixin were not NoInterfaceObject and the "copy of each property" were done via: X.doSomething = Y.doSomething = Mixin.doSomething; then they would in fact test ==. The point is, the spec needs to actually cleart define what "copy of each property" means. Again, I would prefer it to mean that the function objects are distinct. > Implementations, however, will likely process these calls using one internal > implementation of the code for those multiple entry-points. This is the other part that is not clear from the spec, and is certainly not true in Gecko's implementation of "implements" right now. And since doing this significantly increases implementation complexity and carries performance penalties for using "implements" as opposed to using partial interfaces, I'd like to understand whether there are any actual use cases for this sort of thing. I really feel like I'm failing to communicate something here, but I can't figure out quite what that is. -Boris
Received on Tuesday, 19 June 2012 18:30:20 UTC