- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 7 Oct 2009 22:42:47 -0700
- To: 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 Wed, Oct 7, 2009 at 10:03 PM, Cameron McCormack <cam@mcc.id.au> 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. > > Here is an instance of this being reported as a bug, btw: > > https://bugzilla.mozilla.org/show_bug.cgi?id=390411 > How about just don't do that. It is not a problem for a competently written program. That "problem" was created by the program buggering the Host object prototype. Are the "users" expected to be incapable of figuring out a way to write a - getElementsByClass - function? Why encourage such reckless, senseless design of modifying not only foreign objects, but host objects, but not only host objects, but their associated prototype, which is apparently an implementation of certain interfaces. For your "users", a link to Law of Demeter. Done. It is not the sort of thing I would expect most modern scripts to be doing at this point. Most have learned better by now (except Mootools developers, last I checked). Specifying prototype chain for Host object was never a good idea. It is a bad idea because it creates a rigid API from flexible interfaces (DOM, proprietary, legacy, and future interfaces). This is just the tip of the complications to come. Nobody needs that. Garrett
Received on Thursday, 8 October 2009 05:43:20 UTC