What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)
bruant.d at gmail.com
Fri Apr 26 11:21:04 PDT 2013
Le 26/04/2013 17:58, Mark Miller a écrit :
> However, the need for assimilation is history dependent. If there is
> another plausible-enough path to adoption and widespread use of
> promises that does not require assimilation, I would be very happy.
> But I have not found any of the alternatives posted so far to be
> plausible enough.
Let's try. It's pretty much a rehash of what I've proposed already, but
I'm trying here to demonstrate that it is plausible.
Let's first divide the world of existing code using promises (one or
several promise libraries independently) in to categories:
(1) unmaintained code (sitting on a website somewhere, nobody is
modifying the code)
(2) maintained code (deployed in production too, some people do touch
Before the introduction of platform promises, both code works. After the
inclusion of platform promises, (1), oblivious of the fact that anything
has changed still works. After the inclusion of platform promises, only
those in (2) will be of concern.
One idea would be for application using non-platform promises to wrap
platform promises into something they understand.
Developers will need the discipline to mainly use non-platform promises
(as platform promises wouldn't recognize any other object as a promise)
Where should this wrapping occur? Each library can add a check+convert
to all surface API. It doesn't sound that hard (library authors can jump
in to say I'm crazy here).
It imposes all existing project to upgrade all their promise libraries
to a version that wrap natives if they want to use platform promises too.
Hopefully, that should work until an ecosystem (or several) built on top
of platform promises emerge and new projects should be built on top of
this new ecosystem.
So in the end, it takes:
1) new version of libraries to auto-wrap platform promises (preferably
happening in a non-API-breaking way)
2) existing projects upgrade their promise libraries
3) existing projects stick to promises library and don't use platform
features (DOMFuture statics)
4) a platform promise ecosystem emerges
5) new projects only use the new platform ecosystem (or respect 3)
How plausible does this sound?
More information about the es-discuss