conventions for prollyfills

As a prollyfill picks up steam and nears becoming official it seems likely
that you might find multiple things wanting to use it... if those things
are ideas that potentially stack up you can quickly get in a situation
where each one is packaging up another copy of the prollyfill.

let me give you a simple example: promises.  pretty much every piece of
async api I write is using promises.  I have a lib thingA which builds on
another lib things and that provides thingC.  Other than a shared
understanding of promises they are independent concepts.  They are all
using RSVP for promises (with a alias to attach .all to Promise)

Promises are pretty darn close, but given the track record of changes
before standardization and lack of native implementations or final spec
status - I think this is still a prollyfill and my own philosophy is
”forward compatibility”.

This in mind, it might be nice to create a global root object for
prollyfills which could be used to create modernize style feature testing.
In other words, something like:

Prollyfill.Promise = RSVP.Promise;

would allow us to do feature testing and conditionally download support.

Received on Wednesday, 25 September 2013 11:30:57 UTC