Re: Prollyfills and the global namespace / multi-fills

On Wednesday, July 3, 2013 at 8:28 PM, Brian Kardell wrote:
> On Wed, Jul 3, 2013 at 3:13 PM, François REMY
> <francois.remy.dev@outlook.com (mailto:francois.remy.dev@outlook.com)> wrote:
> > 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.


Sorry, it was dumb of me not to paste in the right bit of code from Promise.js. I was hoping you would see:  

(function(global, browserGlobal, underTest) {

.. code…

})(this,
(typeof window !== 'undefined') ? window : {},
this.runningUnderTest||false);



So, yes, you can override what "global" is, what "window" is, etc.  
  
> 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.

Sure, see code above.  

I don't know if JQuery is a prollyfill or if Hitch is. Depends on your definition.    

Also, this can be challenging when given:  

partial interface Navigator {
    readonly    attribute SomeInterface foo;
};


Or something that requires a constructor.  
  
> 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.

Yes, it's a different story with HTML elements because you can't precheck in markup if it's supported.   
> 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.

Sure, so long as there is choice.

Received on Wednesday, 3 July 2013 23:42:47 UTC