Re: Notes from our WebIDL + ES5 phone chat today...

On Oct 7, 2009, at 10:56 PM, Maciej Stachowiak wrote:

>> Here is an instance of this being reported as a bug, btw:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=390411
>
> That bug seems like a slightly different issue than mixins. This is  
> a matter of Gecko redefining inherited methods on derived objects.  
> It seems like this could be fixed for the primary ancestor without  
> requiring anything special to be done for mixins.

Agreed.


> The way WebKit works is that we consider one inherited interface  
> "primary" and delegate to its prototype, but other mixin interfaces  
> are flattened into whatever inherits from it. I suggest that  
> behavior is the right balance of usefulness and practicality of  
> efficient implementation.

Yes, we aim to do that. It is how Dojo maps its mixins onto JS's  
single prototype chain too.

I think everyone involved in the Mozilla code agrees with this at some  
vague level of intent, it's "just" a matter of reverse-engineering  
what WebKit does (open source helps, but your Perl-based IDL code  
generator may not :-P) and doing the work.

On that point, Boris has asked a couple of times for clarification on  
the flattening. The "it" at the end of your sentence:

''we consider one inherited interface "primary" and delegate to its  
prototype, but other mixin interfaces are flattened into whatever  
inherits from it''

seems not to be the same "it" as the one inherited primary interface  
("its"). Do you flatten onto the inheriting interface's prototype? So  
for

interface I : J, K, L

I.prototype.[[Prototype]] is J.prototype and contains J's properties,  
while K's and L's properties are copied onto I.prototype directly?

/be

Received on Thursday, 8 October 2009 17:38:55 UTC