Re: [webcomponents]: <element> Wars: A New Hope

@Rick *"I didn't say Object.create, I said Object.defineProperties"* -
Object.create
was a typo I didn't intend, thank you for catching that, *you're very
helpful*. You misinterpreted what I was alluding to with the
HTMLElementElement stuff, but that's not important now.

*"I think you should get your Object meta APIs straight before having
discussions about them"* - as it happens, I'm well acquainted with the
now-popular native methods and abstractions making their way through TC39
and the JS community. When we developed many of them for MooTools more than
half a decade ago, we always knew the rest of the web would *jump on the
bandwagon* with more advanced JS methods, abstractions, and native
extensions, *eventually*.

I must apologize, it wasn't immediately obvious to me that a nondescript,
passing mention the word "repackaging", was actually an brilliant inference
to an extremely specific list of things implementers and polyfillers would
need to do beyond simply defining a property object - *my bad*. I really
just wanted to make sure I had that list of things right. Alas, I can't
read one word like "repackaging", and use the Force to decrypt such
strikingly specific detail from it - but I guess that's what separates us
less-intelligent simpletons from Jedi like yourself.

Have a wonderful evening Rick.


On Wed, Apr 17, 2013 at 8:46 PM, Rick Waldron <waldron.rick@gmail.com>wrote:

>
>
>
> On Wed, Apr 17, 2013 at 7:33 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>
>> So let me be *crystal clear*:
>>
>> If define() internally does this --> "When the registration line comes,
>> the browser-thing matches <element> instances and supplied property objects
>> by custom element names, uses them to create prototypes, and then calls
>> document.register with respective custom element name and prototype as
>> arguments." - it's doing a hell-of-a-lot more than simply redirecting to
>> Object.create - in fact, I was thinking it would need to do this:
>>
>
> I didn't say Object.create, I said Object.defineProperties. I think you
> should get your Object meta APIs straight before having discussions about
> them.
>
>
>>
>>    - Retain all tagName-keyed property descriptors passed to it on a
>>    common look-up object
>>    - Interact with the portion of the system that handles assessment of
>>    the "registration line", and whether it has been crossed
>>    - and if called sometime after the "registration line" has been
>>    crossed, immediately invokes code that upgrades all in-DOM elements
>>    matching the tagName provided
>>
>> I could be mistaken - but my interest is valid, because if true I would
>> need to polyfill the above detailed items, vs writing something as simple
>> and derpish as: HTMLElementElement.prototype.define = ...alias to
>> Object.create...
>>
> This appears to move the previously static HTMLFooElement.define( tag,
> descriptor ) method and now pollutes the prototype with a method of the
> same name? Why? Do you actually want every instance of HTMLFooElement to be
> able to call a define() method over and over again? I assumed this was a
> once-per-element operation...
>
> At any rate, of course it's not as simple as an alias assignment and no
> one suggested that—perhaps you're not familiar with the definition of the
> word "repackage"? It means to alter or remake, usually to make something
> more appealing. Sounds about right, doesn't it? I think you should be
> careful of what you refer to as "derpish".
>
>
>
> Rick
>
>
>
>>  Dimitri, Scott can you let me know if that sounds right, for polyfill
>> sake?
>>
>> On Wed, Apr 17, 2013 at 4:11 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>>
>>>> *"This is just a repackaging of Object.defineProperties( target,
>>>> PropertyDescriptors ) thats slightly less obvious because the target
>>>> appears to be a string."
>>>> *
>>>> Is another difference that the 'x-foo' doesn't have to be 'known' yet?
>>>> It seems to be a bit more than a repack of Object.defineProperties to me.
>>>>
>>>>
>>> I'm sorry if I was unclear, but my comments weren't subjective, nor was
>>> I looking for feedback.
>>>
>>> Looks like Dimitri agrees:
>>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0306.html
>>>
>>> Rick
>>>
>>>
>>>
>>>>
>>>>
>>>> On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>>>>
>>>>>> Inspired by Allen's and Scott's ideas in the "Benadryl" thread, I dug
>>>>>> into understanding what <element> actually represents.
>>>>>>
>>>>>> It seems that the problem arises when we attempt to make <element>
>>>>>> _be_ the document.register invocation, since that draws the line of
>>>>>> when the declaration comes to existence (the registration line) and
>>>>>> imposes overly restrictive constraints on what we can do with it.
>>>>>>
>>>>>> What if instead, the mental model of <element> was a statement of
>>>>>> intent? In other words, it says: "Hey browser-thing, when the time is
>>>>>> right, go ahead and register this custom element. kthxbai"
>>>>>>
>>>>>> In this model, the proverbial registration line isn't drawn until
>>>>>> later (more on that in a moment), which means that both <element> and
>>>>>> <script> can contribute to defining the same custom element.
>>>>>>
>>>>>> With that in mind, we take Scott's/Allen's excellent idea and twist it
>>>>>> up a bit. We invent a HTMLElementElement.define method (name TBD),
>>>>>> which takes two arguments: a custom element name, and an object. I
>>>>>> know folks will cringe, but I am thinking of an Object.create
>>>>>> properties object:
>>>>>>
>>>>>
>>>>> The are called Property Descriptors.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> HTMLElementElement.define('x-foo', {
>>>>>>     erhmahgerd: { writable: false, value: "BOOKS!" }
>>>>>> });
>>>>>>
>>>>>>
>>>>> This is just a repackaging of Object.defineProperties( target,
>>>>> PropertyDescriptors ) thats slightly less obvious because the target
>>>>> appears to be a string.
>>>>>
>>>>>
>>>>> Rick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> When the registration line comes, the browser-thing matches <element>
>>>>>> instances and supplied property objects by custom element names, uses
>>>>>> them to create prototypes, and then calls document.register with
>>>>>> respective custom element name and prototype as arguments.
>>>>>>
>>>>>> We now have a working declarative syntax that doesn't hack <script>,
>>>>>> is ES6-module-friendly, and still lets Scott build his tacos. Sounds
>>>>>> like a win to me. I wonder how Object.create properties object and
>>>>>> Class syntax could mesh better. I am sure ES6 Classes peeps will have
>>>>>> ideas here.
>>>>>>
>>>>>> So... When is the registration line? Clearly, by the time the parser
>>>>>> finishes with the document, we're too late.
>>>>>>
>>>>>> We have several choices. We could draw the line for an element when
>>>>>> its corresponding </element> is seen in document. This is not going to
>>>>>> work for deferred scripts, but maybe that is ok.
>>>>>>
>>>>>> For <element>s that are imported, we have a nice delineation, since we
>>>>>> explicitly process each import in order, so no problems there.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> :DG<
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>