W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: HTMLElementElement missing a primitive

From: Scott Miles <sjmiles@google.com>
Date: Fri, 8 Mar 2013 12:33:05 -0800
Message-ID: <CAHbmOLbdACMVCQtiZxgXmt=+C0QpCW_T=TV-bGxww+zpJLUhkQ@mail.gmail.com>
To: Erik Arvidsson <arv@chromium.org>
Cc: Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT