Errata:
makePrototypeTwiddlingConstructorForDomNodes needs to know the extendee
var ctor = makePrototypeTwiddlingConstructorForDomNodes(inExtends, inClass);
On Wed, Feb 6, 2013 at 11:59 AM, Scott Miles <sjmi...@google.com> wrote:
> On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson <a...@chromium.org> wrote:
>
>> On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles <sjmi...@google.com> wrote:
>> > Sorry, replace MyButton.super() with MyButton.super.call(this);
>> >
>> >
>> > On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles <sjmi...@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
>>
>
>
