- From: Scott Miles <sjmiles@google.com>
- Date: Fri, 8 Mar 2013 12:33:05 -0800
- To: Erik Arvidsson <arv@chromium.org>
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>
- Message-ID: <CAHbmOLbdACMVCQtiZxgXmt=+C0QpCW_T=TV-bGxww+zpJLUhkQ@mail.gmail.com>
imperative: class XFancier extends XFancy { fancify() { super(); makeFancier(); } ... document.register('x-fancier', XFancier); declarative: <element name='x-fancier' extends="x-fancy"> <script> class XFancier { fancify() { super(); // How do I get inherited fancify? makeFancier(); } On Fri, Mar 8, 2013 at 12:25 PM, Erik Arvidsson <arv@chromium.org> wrote: > On Fri, Mar 8, 2013 at 2:46 PM, Scott Miles <sjmiles@google.com> wrote: > >> I also want to keep ES6 classes in mind. Presumably in declarative form I >> declare my class as if it extends nothing. Will 'super' still work in that >> case? >> > > If you extend nothing (null) as in: > > class Foo extends null { > m() { > super(); > } > } > > super calls will deref null which throws as expected. > > Maybe I don't understand what you are asking? > > >> >> Scott >> >> >> On Fri, Mar 8, 2013 at 11:40 AM, Scott Miles <sjmiles@google.com> wrote: >> >>> Mostly it's cognitive dissonance. It will be easy to trip over the fact >>> that both things involve a user-supplied prototype, but they are required >>> to be critically different objects. >>> >>> Also it's hard for me to justify why this difference should exist. If >>> the idea is that element provides extra convenience, then why not make the >>> imperative form convenient? If it's important to be able to do your own >>> prototype marshaling, then won't this feature be missed in declarative form? >>> >>> I'm wary of defanging the declarative form completely. But I guess I >>> want to break it down first before we build it up, if that makes any sense. >>> >>> Scott >>> >>> >>> >>> On Fri, Mar 8, 2013 at 9:55 AM, Erik Arvidsson <arv@chromium.org> wrote: >>> >>>> If you have a tag name it is easy to get the prototype. >>>> >>>> var tmp = elementElement.ownerDocument.createElement(tagName); >>>> var prototype = Object.getPrototypeOf(tmp); >>>> >>>> On Fri, Mar 8, 2013 at 12:16 PM, Dimitri Glazkov <dglazkov@chromium.org> >>>> wrote: >>>> > On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles <sjmiles@google.com> >>>> wrote: >>>> >> Currently, if I document.register something, it's my job to supply a >>>> >> complete prototype. >>>> >> >>>> >> For HTMLElementElement on the other hand, I supply a tag name to >>>> extend, and >>>> >> the prototype containing the extensions, and the system works out the >>>> >> complete prototype. >>>> >> >>>> >> However, this ability of HTMLElementElement to construct a complete >>>> >> prototype from a tag-name is not provided by any imperative API. >>>> >> >>>> >> As I see it, there are three main choices: >>>> >> >>>> >> 1. HTMLElementElement is recast as a declarative form of >>>> document.register, >>>> >> in which case it would have no 'extends' attribute, and you need to >>>> make >>>> >> your own (complete) prototype. >>>> >> >>>> >> 2. We make a new API for 'construct prototype from a tag-name to >>>> extend and >>>> >> a set of extensions'. >>>> >> >>>> >> 3. Make document.register work like HTMLElementElement does now (it >>>> takes a >>>> >> tag-name and partial prototype). >>>> > >>>> > 4. Let declarative syntax be a superset of the imperative API. >>>> > >>>> > Can you help me understand why you feel that imperative and >>>> > declarative approaches must mirror each other exactly? >>>> > >>>> > :DG< >>>> > >>>> >>>> >>>> >>>> -- >>>> erik >>>> >>> >>> >> > > > -- > erik > > >
Received on Friday, 8 March 2013 20:33:38 UTC