What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

David Bruant 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 
the code)

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?

David


More information about the es-discuss mailing list