jQuery was just an example. > The basic idea is that you feature detect for ES6 Promises. If that test passes, then you implement jQuery.Deferred using a Promise subclass (which would do assimilation for backward compatibility reasons). Otherwise you implement it the old-fashioned way.
Hold on there. If they already do assimilation, why would you even inherit? So you're saying that promise library authors should rearchitect their entire libraries, and that solution is better than them just adding a flag to their prototype which says "convertableToPromise = true;" ? Which can be monkey patched by end users too? How is this even remotely practical? This is my list of options and what I think about their practicality - full reserving a commonplace method named "then" - impractical, error prone and unfriendly to both existing and new code (accidental then is very possible) - reserving the combination of "then" and "convertableToPromise" - practical, sensible tradeoff (as symbol-based branding isnt available, and accidentally adding both properties isn't very possible) - expecting promise libraries to upgrade by simply setting a flag convertableToPromise = true - practical (can also be monkey-patched by end-users) although painful for existing promise libraries and users at the beginning - expecting non-promise libraries to mark their prototypes with convertableToPromise = false (assuming true by default) - slightly less practical, but painless for existing promise libraries and users at the beginning. (The intent of course is to flip the switch later) - using symbols for branding/anti-branding - impractical, because it cannot be shimmed - expecting promise libraries to upgrade by subclassing Promise - impractical, some (like Bluebird) have complex, hand tuned performance-optimized internals which even makes them faster than the native implementation, and some have extra features which will need to be re-done in a new way. (full rearchitecting) If you ask me, the only viable options are "ghetto branding" and "ghetto anti-branding". On Fri, Dec 20, 2013 at 6:38 PM, Kevin Smith <[email protected]> wrote: > Okay, so how will end users or jQuery authors upgrade their promises to >> become ES6-compliant? > > > I don't know enough about jQuery's internals to write convincing code, but > the basic idea is that you feature detect for ES6 Promises. If that test > passes, then you implement jQuery.Deferred using a Promise subclass (which > would do assimilation for backward compatibility reasons). Otherwise you > implement it the old-fashioned way. > > Application developers who are going to hook into the new DOM API's need > to upgrade their jQuery. > > Of course, jQuery promises will still over-assimilate objects which have a > `then` method but aren't "thenable", but that's jQuery's backward > compatibility problem, not the entire language's. > > Am I missing something? I usually do... : ) > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
