- From: Scott Miles <sjmiles@google.com>
- Date: Wed, 6 Feb 2013 12:49:12 -0800
- To: Daniel Buchner <daniel@mozilla.com>
- Cc: Erik Arvidsson <arv@chromium.org>, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
- Message-ID: <CAHbmOLb43CL=ssJnA5W1T_2w7DdGD1NZeWGX6fkuvHc6KUQ7wQ@mail.gmail.com>
Arg, I messed up the link there. Corrected: http://jsfiddle.net/cEmZq/1/ On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles <sjmiles@google.com> wrote: > Sorry for the flood, but here is another version that shows inheriting > from custom elements (Webkit/FF only). > > http://jsfiddle.net/cEmZq/ > > > On Wed, Feb 6, 2013 at 12:43 PM, Scott Miles <sjmiles@google.com> wrote: > >> Yes, it's not intended to work in IE ... I used __proto__. >> >> >> On Wed, Feb 6, 2013 at 12:41 PM, Daniel Buchner <daniel@mozilla.com>wrote: >> >>> Scott: is this example not intended to work in IE9? It throws, the >>> output object is missing the 'oranginate' method. >>> >>> Daniel J. Buchner >>> Product Manager, Developer Ecosystem >>> Mozilla Corporation >>> >>> >>> On Wed, Feb 6, 2013 at 12:32 PM, Scott Miles <sjmiles@google.com> wrote: >>> >>>> There were several errors in my pseudo-code, here is a working version: >>>> >>>> http://jsfiddle.net/yNbnL/1/ >>>> >>>> S >>>> >>>> >>>> On Wed, Feb 6, 2013 at 12:01 PM, Scott Miles <sjmiles@google.com>wrote: >>>> >>>>> Errata: >>>>> makePrototypeTwiddlingConstructorForDomNodes needs to know the >>>>> extendee >>>>> >>>>> var ctor = makePrototypeTwiddlingConstructorForDomNodes(inExtends, >>>>> inClass); >>>>> >>>>> >>>>> On Wed, Feb 6, 2013 at 11:59 AM, Scott Miles <sjmiles@google.com>wrote: >>>>> >>>>>> On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson <arv@chromium.org>wrote: >>>>>> >>>>>>> On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles <sjmiles@google.com> >>>>>>> wrote: >>>>>>> > Sorry, replace MyButton.super() with MyButton.super.call(this); >>>>>>> > >>>>>>> > >>>>>>> > On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles <sjmiles@google.com> >>>>>>> wrote: >>>>>>> >> >>>>>>> >> So, neglecting issues around the syntax of document.register and >>>>>>> the >>>>>>> >> privatization of callbacks, is it fair to say the following is >>>>>>> the intended >>>>>>> >> future: >>>>>>> >> >>>>>>> >> class MyButton extends HTMLButtonElement { >>>>>>> >> constructor() { >>>>>>> >> super(); >>>>>>> >> // make root, etc. >>>>>>> >> } >>>>>>> >> } >>>>>>> >> document.register('x-button', MyButton); >>>>>>> >> >>>>>>> >> If so then can we do this in the present: >>>>>>> >> >>>>>>> >> MyButtonImpl = function() { >>>>>>> >>>>>>> What do you mean here? >>>>>>> >>>>>>> >> MyButton.super(); >>>>>>> >>>>>>> Did you get that backwards? I don't see how MyButtonImpl can be >>>>>>> derived from MyButton. >>>>>>> >>>>>> >>>>>> Its not. The 'super' means 'the super-class constructor for MyButton >>>>>> that does not include magic DOM object generation' (in this case, >>>>>> HTMLButtonElement). For MyDerivedButton, MyDerivedButton.super would point >>>>>> to MyButtonImpl. >>>>>> >>>>>> The existence of MyButtonImpl is an unfortunate side-effect of >>>>>> needing a generated constructor. >>>>>> >>>>>> The idea is to correspond as closely as possible with the ES6 >>>>>> version. MyButtonImpl goes away in ES6, it's purpose in the meantime is >>>>>> just to provide something that looks like a proper class. >>>>>> >>>>>> I could write it this way: >>>>>> >>>>>> *MyButton = function() { >>>>>> >>>>>> MyButton.super(); >>>>>> // make root, etc. >>>>>> }; >>>>>> MyButton.prototype = Object.create(HTMLButtonElement, { ... });* >>>>>> * >>>>>> MyButton = document.register(‘x-button’, MyButton); >>>>>> * >>>>>> >>>>>> Written this way, MyButton no longer refers to the constructor you >>>>>> specified, but instead refers to the generated constructor. This is >>>>>> conceptually cleaner, but it's a bit tricky. For maximum clarity, I named >>>>>> the internal version MyButtonImpl in my example code, but there is no >>>>>> reason to have that symbol. >>>>>> >>>>>> >>>>>>> >>>>>>> >> // make root, etc. >>>>>>> >> }; >>>>>>> >> MyButtonImpl.prototype = Object.create(HTMLButtonElement, { ... >>>>>>> }); >>>>>>> >> >>>>>>> >> // the ‘real’ constructor comes from document.register >>>>>>> >> // register injects ‘super’ into MyButton >>>>>>> >> MyButton = document.register(‘x-button’, MyButtonImpl); >>>>>>> >>>>>>> What is the relationship between MyButton and MyButtonImpl? >>>>>>> >>>>>>> If MyButton.__proto__ === MyButtonImpl and >>>>>>> MyButton.prototype.__proto__ === MyButtonImpl.prototype then this >>>>>>> might work (but this cannot be polyfilled either). >>>>>>> >>>>>>> >>>>>> MyButton.prototype == MyButtonImpl.prototype or >>>>>> MyButton.prototype.__proto__ == MyButtonImpl.prototype, depending on needs. >>>>>> >>>>>> MyButton itself does magic DOM construction work that we cannot do >>>>>> with normal inheritance, then invokes MyButtonImpl. MyButtonImpl is never >>>>>> used as a constructor itself (not as an argument to 'new' anyway). >>>>>> >>>>>> From the user's perspective, he has made a single class which >>>>>> implements his element (the goal!). The unfortunate name shenanigan (I >>>>>> called my class MyButtonImpl, but after 'register' I refer to it as >>>>>> MyButton) is the simplest way I could conceive to overcome the 'generated >>>>>> constructor' problem. >>>>>> >>>>>> To be clear, everything I come up with is intended to polyfill >>>>>> (modulo my error), because I generally am writing those myself (at first >>>>>> anyway). One version might look like this: >>>>>> >>>>>> document.register = function(inExtends, inClass) { >>>>>> var ctor = makePrototypeTwiddlingConstructorForDomNodes(inClass); >>>>>> ctor.prototype = inClass.prototype; >>>>>> addToTagRegistry(inExtends, ctor, inClass); >>>>>> ctor.super = getClassForExtendee(inExtends); >>>>>> return ctor; >>>>>> }; >>>>>> >>>>>> >>>>>> -- >>>>>>> erik >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
Received on Wednesday, 6 February 2013 20:49:41 UTC