- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 26 Apr 2013 20:21:04 +0200
- To: Mark Miller <erights@gmail.com>
- CC: Andreas Rossberg <rossberg@google.com>, Dean Landolt <dean@deanlandolt.com>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Dean Tribble <tribble@e-dean.com>, es-discuss <es-discuss@mozilla.org>
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
Received on Friday, 26 April 2013 18:21:35 UTC