Re: document.register and ES6

On Fri, Feb 8, 2013 at 12:47 PM, Scott Miles <sjmiles@google.com> wrote:
>>> 1. Because an element with tagName === 'my-button' will not be an
>>> HTMLButtonElement instance.
>
> Yes, but as I mentioned, the latest notion I undersstood was that we would
> support <button is='my-button'> syntax in this case.
>
>>> 2. We cannot return the correct function object from document.register.
>>> 2. Because ES5 cannot set @@create so you need to create a new function
>>> that wraps the original.
>
> Yes, so all ES5 solutions must return some generated function. This is a big

Correction. All ES5 shims.

> reason we're going through this exercis and why I attempted to isolate this
> requirement in a separate function that could then evacipate when ES6
> solutions become possible.
>
>>> 1 can be implemented using 3.
>
> Yes, but given 3, document.register can be spec'd exactly as we want, and
> the cost of requiring the function wrapper is isolated elsewhere. Given 1,
> document.register has to be specified with the technical debt inside (take
> an extra parameter, return a function).

I feel like we are going in circles. document.register can be spec'ed
to do the right thing. It is shims that are imposing this limitation.

> Having said all that, you actually preferred (2). My only good argument
> against (2) is that it requires document.register to return something, which
> is not an ability it will need at some point in the future.
>
>>>
> There is no need to wait for ES6 class syntax.
> If we didn't need to shim this we would not need to have two different
> functions for one entity.
> <<
>
> The critical bit is not ES6 class syntax, it's that you cannot extend DOM
> 'classes' with JS. That's what's driving all of this, and afaik, affects
> native implementations just as much as shims. Probably I should have
> separated this from the 'class' question more clearly, but my goal was to
> reach a destination that could smoothly evolve with both enhancements.
>
>
> On Fri, Feb 8, 2013 at 9:34 AM, Erik Arvidsson <arv@chromium.org> wrote:
>>
>> On Fri, Feb 8, 2013 at 12:18 PM, Scott Miles <sjmiles@google.com> wrote:
>> > Sorry, I'm not quite following.
>> >
>> > 1. We cannot really extends anything else but
>> > HTMLElement/HTMLUnknownElement.
>> > 2. We cannot return the correct function object from document.register.
>> >
>> > I don't see why these are true?
>>
>> 1. Because an element with tagName === 'my-button' will not be an
>> HTMLButtonElement instance.
>> 2. Because ES5 cannot set @@create so you need to create a new
>> function that wraps the original.
>>
>> > (Btw note that my 'solution 3' removes the 'return a function from
>> > register'
>> > and instead puts that into the intermediate function.)
>>
>> 1 can be implemented using 3.
>>
>> > Also, you and Dimtiri keep talking about polyfills, but I'm talking
>> > about
>> > the *spec* first.
>> >
>> > Are you saying that the spec for document.register will simply require
>> > ES6
>> > and everything else we be some kind of hack? I guess I thought the idea
>> > was
>> > to spec document.register such that it could be implemented by browser
>> > vendors *before* class-syntax or JS inheritance for DOM was available.
>> > Am I
>> > misunderstanding?
>>
>> I think you are misunderstanding some things. There is no need to wait
>> for ES6 class syntax. ES6 class syntax is just syntactic sugar over
>> ES5 + __proto__. ES6 has formalized the semantics for "new Expr" to
>> use two phases. This cannot be done in useland code but we can achieve
>> the same using ES5 spec internals by mutating [[Construct]] (instead
>> of @@create in ES6).
>>
>> A lot of these later discussions have been driven by a desire to be
>> able to shim this. If we didn't need to shim this we would not need to
>> have two different functions for one entity.
>>
>> --
>> erik
>
>



-- 
erik

Received on Friday, 8 February 2013 18:51:21 UTC