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 <dan...@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 <sjmi...@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 <dan...@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 <sjmi...@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 <dan...@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 <sjmi...@google.com>wrote: >>>>> >>>>>> On Wed, Feb 6, 2013 at 1:27 PM, Daniel Buchner <dan...@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> >>>>>> >>>>> >>>>> >>>> >>> >> >
