Re: document.register and ES6

>> 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 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).

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
>