- From: Daniel Buchner <daniel@mozilla.com>
- Date: Wed, 6 Feb 2013 14:41:49 -0800
- To: Scott Miles <sjmiles@google.com>
- Cc: Erik Arvidsson <arv@chromium.org>, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
- Message-ID: <CAHZ6zJF4sGFihaWYhXfCqT6OEpdEHM9G3+WjUESbDy-5fDLvvw@mail.gmail.com>
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> >>>>> >>>> >>>> >>> >> >
Received on Wednesday, 6 February 2013 22:42:46 UTC