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 <zenparsing at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131220/132a482a/attachment.html>

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".