Re: Question about implements statements

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