> 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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
