Re: document.register and ES6

If that works, then what's the problem? It only need be done once per
component.

I'm still confused, because it seems to me that 'unbaked object allowance
route' == components only work in IE if specified using tortured syntax.

That's no bueno IMO.


On Wed, Feb 6, 2013 at 2:41 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> Short of running Object.getOwnPropertyNames on the existing node > then
> iterating over each to grab the property descriptor with
> Object.getOwnPropertyDescriptor to rebuild an unbaked object > and finally
> setting the properties with Object.setProperties, I am unaware of how to do
> so - is there an easier way? If so I would love to not do the above or go
> the unbaked object allowance wrapper route :)
>
> Daniel J. Buchner
> Product Manager, Developer Ecosystem
> Mozilla Corporation
>
>
> On Wed, Feb 6, 2013 at 2:28 PM, Scott Miles <sjmiles@google.com> wrote:
>
>> Seems like you decided that descriptor syntax is *necessary* for IE
>> compatibility. I'm 80% sure it is not.
>>
>> S
>>
>>
>> On Wed, Feb 6, 2013 at 2:10 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>
>>> I guess it isn't a show stopper for poly-*ish*-fills, I would just wrap
>>> the native document.register method where it is present > sniff the
>>> incoming prototype property value to detect whether it was baked > cache
>>> the unbaked prototype > then pass a baked one to the native method.
>>>
>>> Of course this means we'll (I'll) be evangelizing a polyfill with a
>>> slightly augmented wrapper for taking unbaked objects, but for IE
>>> compatibility devs will probably offer their first born, so I doubt they'll
>>> bat an eye at such a benign incongruity.
>>>
>>> Daniel J. Buchner
>>> Product Manager, Developer Ecosystem
>>> Mozilla Corporation
>>>
>>>
>>> On Wed, Feb 6, 2013 at 2:01 PM, Scott Miles <sjmiles@google.com> wrote:
>>>
>>>> Remember where we started: absurdly clean ES6 class syntax.
>>>>
>>>> Requiring class definition class using property descriptors is a
>>>> radical march in the other direction.
>>>>
>>>> I'm hardcore about syntactical tidiness. The reason I'm not freaking
>>>> out about defineProperties is IMO because I can avoid it when I don't need
>>>> it (which is about 99% of the time).
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Wed, Feb 6, 2013 at 1:50 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>>>
>>>>> I just made sure it worked, and it does. As for developers freaking
>>>>> out, I really don't believe they would. If that was the case,
>>>>> Object.defineProperties should be causing a global pandemic of whopperdeveloper freakouts (
>>>>> http://www.youtube.com/watch?v=IhF6Kr4ITNQ).
>>>>>
>>>>> This would give us easy IE compat for the whole range of property
>>>>> types, and I'm willing to all but guarantee developers will have a bigger
>>>>> freakout about not having IE9 support than the prototype property of
>>>>> document.register taking both a baked and unbaked object.
>>>>>
>>>>> Daniel J. Buchner
>>>>> Product Manager, Developer Ecosystem
>>>>> Mozilla Corporation
>>>>>
>>>>>
>>>>> On Wed, Feb 6, 2013 at 1:34 PM, Scott Miles <sjmiles@google.com>wrote:
>>>>>
>>>>>> On Wed, Feb 6, 2013 at 1:27 PM, Daniel Buchner <daniel@mozilla.com>wrote:
>>>>>>
>>>>>>> So you're directly setting the user-added methods on matched
>>>>>>> elements in browsers that don't support proto, but what about accessors?
>>>>>>>
>>>>>>
>>>>>> I believe those can be forwarded too, I just didn't bother in my
>>>>>> fiddle.
>>>>>>
>>>>>>
>>>>>>> Equipped with the unbaked prototype descriptor, in your upgrade
>>>>>>> phase, you should be able to simply bake the node with:
>>>>>>> Object.defineProperties(element, unbakedPrototypeDescriptor) - right?
>>>>>>>
>>>>>>
>>>>>> Yes, but I believe developers would freak out if we required them to
>>>>>> provide that type of descriptor (I would).
>>>>>>
>>>>>>  <snip>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>