Re: Prollyfills and the global namespace / multi-fills

On Wednesday, July 3, 2013 at 6:58 PM, François REMY wrote:

> > What does "module" mean here? AMD? NPM? CommonJS?
>  
>  
> An object that is self-contained. That includes any kind of module, even  
> just:
>  
> window.myProllyfill = {
> Abc: function() {
> ...
> },
> Def: function() {
> ...
> }
> }
>  

Oh, then no. That's not the way to do it. It depends on the definition of the interface.  

IMO, the right (™) way to do it is like Promises are done here (wrap in anonymous function):

https://github.com/slightlyoff/Promises/blob/master/polyfill/src/Promise.js

And if you want to go a little more extreme (i.e., closer to what you need to do to make a WebIDL conforming implementation) you need to create both an "interface object" and an "interface prototype object".  

See for example:
https://github.com/marcoscaceres/adlib.js/blob/master/lib/interfaces/requestMIDIAccess.js
  
>  
>  
> > - when you use some global namespace, use a prefix (no code should use  
> > your
> > function by mistaking it for a native implementation)
>  
>  
>  
> Redefining an existing prollyfill that (you think) sucks by another one is  
> the best way to have problems because some code most probably rely on the  
> "sucking" implementation. That's why you simply do not want prollyfill to  
> clash with anything hence special names and prefixes.

Depends on who you are building it for. If you are building it for a standards org, then you want it to be as close to the metal as it can be (See Promises prollyfill… I rely on that in my projects, and would be quite annoyed if Alex suddenly prefixed it).    
> You don't have to prefix everything, just enough to make sure people can use  
> the polyfill and still be sure no code that never "met" the prollyfill will  
> use it by mistake.  

From my own experience, this sounds good on paper, but it doesn't work in practice. It requires too much decline for too little return.

Received on Wednesday, 3 July 2013 18:07:36 UTC