- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 07 Oct 2009 22:56:32 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Garrett Smith <dhtmlkitchen@gmail.com>, Travis Leithead <travil@microsoft.com>, Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>, "Mark S. Miller" <erights@google.com>, Doug Schepers <schepers@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Oct 7, 2009, at 10:03 PM, Cameron McCormack wrote: > Cameron McCormack: >>> Being able to do >>> >>> EventTarget.prototype.addEventListener = … >>> >>> instead of doing it on every mixin prototype object, which is how it >>> would need to be done as currently specified. >>> > > Garrett Smith: >> I see. Why is that a problem? > > It’s a problem because you might not know all of the places this mixin > has been mixed in, and even if you do, it seems like more work than > should be necessary. Being able to prototype hack mixins in a single place would be nice. But I think that currently no browser really supports that, and it seems like it would be tricky to implement. I suggest maybe this shouldn't be a feature for Web IDL 1.0, since no browser has the behavior, no spec using Web IDL requires it, and it can always be added later. > > 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. 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. Regards, Maciej
Received on Thursday, 8 October 2009 05:57:08 UTC