> I think you are probably overstating the burden on library authors in
order to make your proposal look better.   : )

I don't feel I'm overstating the burden. I thought that the pains of having
to subclass to get correct interoperability behavior are well understood
from experiences with other object-oriented programming languages. Thats
one of the reasons for implicit interfaces...

You're right that backward compatibility has probably been overestimated.
And indeed I'm biased - I am using a promise library in day-to-day coding
([Bluebird][1]) which will be impossible to re-architect by inheriting from
built-in Promises. I'm using it because it gives me performance, long stack
support, filtered catch i.e. `.catch(predicate, handler)` and other great
goodies.

But after adding promises to the language, the first pains will be felt by
promise users and promise library authors, as they're the most likely to
adopt them quickly.

Only later when promises start becoming more and more commonplace (with
more DOM APIs producing them) the pains of reserving a `.then` method
become potentially greater. Hopefully all promise users would patch their
libraries in time for ES7 by marking and it will be possible to flip the
switch to the other state (start assuming `convertableToPromise = false`).

I honestly believe that my transitional proposal causes the smallest amount
of overall pain. If I felt that another proposal is less painful I'd gladly
accept it instead (e.g. I'm still not sure if starting with assuming
`convertableToPromise = true` is better)

[1]: https://github.com/petkaantonov/bluebird




On Fri, Dec 20, 2013 at 7:18 PM, Kevin Smith <zenparsing at gmail.com> wrote:

> Hold on there. If they already do assimilation, why would you even
>> inherit?
>
>
> So that the system will see jQuery's assimilating promises as real
> promises.
>
>
>> 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?
>
>
> I think you are probably overstating the burden on library authors in
> order to make your proposal look better.   : )
>
> Anyway, there's no point arguing about it.  I just thought it would be fun
> to see what a good solution that prioritizes the future would look like.  I
> think I've convinced myself that the backward compatibility constraint has
> been overestimated (probably because those working in the space also author
> promise libraries).
>
> But like I said:  no point in arguing over it.
>
>
> _______________________________________________
> 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/9c788435/attachment.html>

> I think you are probably overstating the burden on library authors in order to make your proposal look better.   : )

I don't feel I'm overstating the burden. I thought that the pains of having
to subclass to get correct interoperability behavior are well understood
from experiences with other object-oriented programming languages. Thats
one of the reasons for implicit interfaces...

You're right that backward compatibility has probably been overestimated.
And indeed I'm biased - I am using a promise library in day-to-day coding
([Bluebird][1]) which will be impossible to re-architect by inheriting from
built-in Promises. I'm using it because it gives me performance, long stack
support, filtered catch i.e. `.catch(predicate, handler)` and other great
goodies.

But after adding promises to the language, the first pains will be felt by
promise users and promise library authors, as they're the most likely to
adopt them quickly.

Only later when promises start becoming more and more commonplace (with
more DOM APIs producing them) the pains of reserving a `.then` method
become potentially greater. Hopefully all promise users would patch their
libraries in time for ES7 by marking and it will be possible to flip the
switch to the other state (start assuming `convertableToPromise = false`).

I honestly believe that my transitional proposal causes the smallest amount
of overall pain. If I felt that another proposal is less painful I'd gladly
accept it instead (e.g. I'm still not sure if starting with assuming
`convertableToPromise = true` is better)

[1]: https://github.com/petkaantonov/bluebird