Re: document.register and ES6

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

We aren't circling because you just zeroed in on the crux of my likely
misunderstanding.

Are you saying that browsers can implement document.register today, but
manipulating the guts of the constructor I'm registering? I realize now
that may be the point of the original part of this thread, and I just
didn't understand it.

Scott


On Fri, Feb 8, 2013 at 10:50 AM, Erik Arvidsson <arv@chromium.org> wrote:

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