Re: Prollyfills and the global namespace / multi-fills

On Wed, Jul 3, 2013 at 3:13 PM, François REMY
<francois.remy.dev@outlook.com> 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.
>
>
>
>
>> 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.


I think what I am saying here doesn't really exclude much does it?
I don't think Alex should be defining "Alex's promises" - rather - I
am saying is make it possible for the author to pass in the object it
gets attached to... Lots of things use the approach for running in
both node and the browser - node has no 'window' - so you pass in
'global' and vice-versa.   Pretty simple practice: Author defined -
that is how imports and modules work in almost every language, not
just JavaScript.

Marcos, if you are feeling brave, pass in window.  If you are someone
evaluating for the spec, use window.  For everyday use in situations I
would really like to use prollyfills - personally, I think that is a
dangerous thing to do.  I don't want things breaking in my working
site when the native implementation evolves to something that doesn't
match.  I have other things to do.  I'd like to pass in Hitch or
JQuery or whatever and use it as a prollyfilled thing.

As I said, I'm not saying it has to be a *rule* and you could get
carried away - but I think you are better off following simple
practices to dodge the footguns.  If I proposed an element, it is
namespaced already, no worry about that very specific definition being
conflated with something else that might not be a perfect match.  We
can easily use the same approach in a lot of cases and avoid the worst
of things... If we try to think about things in layers we should get
independent prollyfills that can be plugged together by a larger
framework and provide the sorts of protections I am looking for while
still being able maintain pretty much the same parity you are talking
about.



--
Brian Kardell :: @briankardell :: hitchjs.com

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