In my excitement for getting something that worked on the Big Three
(webkit, IE, FF), I inadvertently cheated by adding an extra parameter to
'document.register'.
TL;DR version:
Solutions to the extra parameter problem:
1. go ahead and have an (optional) extra parameter to document.register
MyButton = function() { ... };
MyButton.prototype = { ... };
MyButton = document.register('x-button', MyButton, 'button');
2. require user to chain prototypes himself and infer the tagName from the
prototype
MyButton = function() { ... };
// making prototype requires icky DefineProperty syntax
// on IE the only purpose of chaining the prototype is for tagName
inference
MyButton.prototype = Object.create(HTMLButtonElement.prototype, { });
MyButton = document.register('x-button', MyButton);
3. introduce an intermediate method to build the 'class':
MyButton = function() { ... };
MyButton.prototype = { ... };
MyButton = document.extendElement('button', MyButton);
document.register('x-button', MyButton);
Right now I'm preferring (3). WDTY?
===
Long version:
Recall that the goal is to support the simple notion of: make class,
register to tag. So,
class MyButton extends HTMLButtonElement...
document.register('x-button', MyButton);
My last proposed non-ES6 version had syntax like this:
MyButton = function() { ... };
MyButton.prototype = { ... };
MyButton = document.register('x-button', MyButton, 'button');
The third parameter serves two purposes: (1) allows register to chain the
correct prototype (HTMLButtonElement.prototype) to MyButton.prototype and
(2) allows register to generate an appropriate constructor (i.e. one the
instantiates a 'button' element).
Trying to remove the third parameter created some new quandries.
One avenue is to suggest the developer set up the inheritance chain outside
of register. This is immediately appealing because it's very close to the
'goal syntax'. IOW,
MyButton = function() { ... };
MyButton.prototype = Object.create(HTMLButtonElement.prototype, { });
MyButton = document.register('x-button', MyButton);
Btw: this form requires inferring the tag name 'button' from
HTMLButtonElement.prototype, which AFAIK, is not as easy as it sounds.
There are two potential downsides (1) adding properties to
MyButton.prototype requires property descriptors (or some helper function
the user must write), (2) on IE we aren't using the chained prototype
anyway.
An alternative would be to introduce another method, something like
'document.extendElement'. Usage would be like so:
MyButton = function() { ... };
MyButton.prototype = { ... };
MyButton = document.extendElement('button', MyButton);
document.register('x-button', MyButton);
Scott
On Thu, Feb 7, 2013 at 3:15 PM, Dimitri Glazkov <dglaz...@google.com> wrote:
>
>
>
> On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
>
>> On 2/6/13 5:07 PM, Erik Arvidsson wrote:
>>
>>> This refactoring is needed for ES6 anyway so it might be worth looking
>>> into no matter what.
>>>
>>
>> Well, yes, but it's a matter of timeframes. It's incredibly unlikely
>> that a complete refactoring of how functions are implemented (which is what
>> I was given to understand would be required here) could be done in the next
>> several months to a year.... I doubt we want to wait that long to do
>> document.register.
>
>
> This is a valid and important concern. Boris, in your opinion, what is the
> most compatible way to proceed here? I see a couple of options, but don't
> know how difficult they will be implementation-wise:
>
> 1) Expose the ability to override [[Construct]]. Arv tells me that he
> spoke with V8 peeps and they think they can do this fairly easily. How's
> the SpiderMonkey story looking here?
>
> 2) Until ES6 is here, return a generated constructor from
> document.register, which is the approach that Scott/Arv/Daniel came up with
> for polyfills. Effectively, this generated constructor will serve as the
> surrogate [[Construct]] override.
>
> 3) ...
>
> 4) PROFIT
>
> :DG<
>
