Re: Prollyfills and the global namespace / multi-fills

On Wednesday, July 3, 2013 at 8:13 PM, François REMY wrote:

> > Yes it is, it's supposed to exactly match (as much as it can in JS).
>  
>  
> Well, it matches the *current* spec. If someone use that code in production,  
> in a few time it will stop to match.

Why?  
> > This is where you and I are speaking past each other: When
> > I implement a prollyfill, I often implement a W3C spec. If
> > there was no W3C spec, then yes! your rule of "don't put
> > your dirty prollything-a-maggig into the global namespace!"
> > applies :)
>  
>  
> That's incorrect. As long as the spec isn't at least a Candidate  
> Recommendation, it's inappropriate to call this a W3C spec. "Publication as  
> a Working Draft does not imply endorsement by the W3C Membership. This is a  
> draft document and may be updated, replaced or obsoleted by other documents  
> at any time. It is inappropriate to cite this document as other than work in  
> progress."

The above also applies at PR too, but this is not really helpful. We all know  "W3C spec" === a spec being worked on by some W3C working group.  
  
> If the goal is to polyfill an existing REC/CR spec, it's okay not to use  
> prefixes, because you can test your spec against test cases, and you can  
> match existing implementations.  

The whole point of the stuff I'm building is so to avoid what is discussed in the manifesto: stop gawd awful APIs from being put into the platform _way_ before they get anywhere near CR (… even way before Last Call). Look at the over 100+ API changes that have occurred to Web MIDI or the total rewrite of the Telephony API. In both cases (specially in Telephony), those changes were driven by my prollyfills. Got to the point where I took over as lead editor for Telephony. This was not intentional - but it shows *the power of the prollyfill * to influence the direction of a spec :)  
> If you're prollyfilling on the basis of a  
> draft, I see not using prefixes as a huge mistake. If it's an "official"  
> polyfill supported by the w3c, it's not a problem to use  
> "experimental.Promise" or "w3.Promise" but I would not go as far saying that  
> an implementation of a draft can be considered good enough to become a  
> non-prefixed thing.

Ok, I can see where there could be potential clashes for unmaintained code. But I think this would be rare. If you opt to put in a prollyfill, then it's likely you know what you are doing.     
> Non-conformant polyfills have become a huge issues for library authors, and

polyfills, sure. But prollys?   
>  
> they need more and more work to detect and avoid them. That should not be  
> the case in an ideal world.

The world is messy, unfortunately.  i'm not against what you are saying, I'm just thinking there is a differentiation to be made between a library and prollyfill (which is intended to inform a standardization process, for instance).  
> > I want to be able to use window.Promise.whatever()
> > like the real thing was there. I don't want to have
> > to alias my code.
>  
>  
>  
> That's okay, but then the prollyfill has to be clearly marked as "/!\ do not  
> use this in production /!\".

Sure, if it's bad. But if it's good and works, then what's the problem?   
> I'm afraid that people will use it in  
> production and will face issues later on. The goal of a sucessful prollyfill  
> is that using it on your website will not make it break when the browser  
> implements the feature or when you add some new code on the page that expect  
> a final implementation. That requires the usage of namespaces/prefixes.  

I think we have to agree to disagree here. But I'm always open to change my mind on this given data that shows this.

Received on Wednesday, 3 July 2013 19:28:46 UTC