Re: Prollyfills and the global namespace / multi-fills

> 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.



> 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."

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. 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.

Non-conformant polyfills have become a huge issues for library authors, and 
they need more and more work to detect and avoid them. That should not be 
the case in an ideal world.



> No, they changed again… it's promise. But they
> promised not to change it again in the future ;-P

:-)



> 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 /!\". 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.

Received on Wednesday, 3 July 2013 19:13:29 UTC