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

On Oct 8, 2009, at 10:36 AM, Brendan Eich wrote:

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

You can feel free to ask me or Sam Weinig for help with the details.  
I've encouraged Sam to join this mailing list. He did most of the work  
on our bindings code generator and the bindings themselves.

Note: we're also open to changing the details; it may be that not  
every single thing we've done makes sense.

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

Yes, that's basically how it works.

There's a few complications:

1) Some interfaces are "extra interfaces" rather than inherited. For  
example, anything that implements Document is supposed to implement  
DocumentView, DocumentStyle, DocumentCSS, DocumentEvent, and probably  
other stuff. We have a few ways of modeling this kind of situation:
     a) In the normal case, we cheat and represent non-inherited extra  
interfaces with multiple inheritence in our IDL. We'll probably update  
this to support Web IDL "implements" as we align our syntax with Web  
IDL.
     b) Sometimes, when there's exactly one interface that is supposed  
to also implement another, we just merge the methods and attributes  
into the main interface. So our Document.idl includes all the stuff  
from DocumentEvent, DocumentCSS, and so forth. I'd like to eventually  
phase this out so our IDL can better match the specs.

To address the specific example that Boris asked about:

> "a <div>" -> HTMLDivElement -> HTMLElement -> Element -> Node
>
>   ... EventTarget ...
>
> How is EventTarget related to the prototype chain of the <div>?   
> Which object are EventTarget's methods "flattened" onto?

The prototype chain looks like this:

<div> instance --> HTMLDivElement.prototype --> HTMLElement.prototype  
--> Element.prototype --> Node.prototype --> Object.prototype

EventTarget is a mix-in interface added at the Node level - we say all  
Nodes are event targets. So EventTarget methods appear on  
Node.prototype. Since Node is a leaf in the IDL, we write it like this:

interface Node : Object, EventTarget { // ...

This makes Object the primary ancestor (which it would be by default  
if Node did not inherit from anything), and EventTarget an additional  
ancestor, which means its properties end up reflected on Node itself.

I think this is simpler than what is in Web IDL right now, and  
sufficient for most Web developer needs.

Regards,
Maciej

Received on Thursday, 8 October 2009 18:00:58 UTC