Re: document.register and ES6

Ok, thanks for your patience Erik. I realize now you STARTED with how the
spec should look. So, I can focus on shim now and stop bothering you.

S


On Fri, Feb 8, 2013 at 10:57 AM, Scott Miles <sjmiles@google.com> wrote:

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