- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 3 Jul 2013 18:44:55 +0100
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Brian Kardell <bkardell@gmail.com>, public-nextweb@w3.org
On Wednesday, July 3, 2013 at 6:10 PM, François REMY wrote:
> I agree with you here.
>
> I think good guidelines are:
> - create a module if possible (people could decide to import it on the
> global namespace, but that's an opt-in)
What does "module" mean here? AMD? NPM? CommonJS?
> - when you use some global namespace, use a prefix (no code should use your
> function by mistaking it for a native implementation)
This is sometimes trickier than it sounds. If your object spawns new objects, those objects will have to be prefixed also, etc. This makes everything pretty ugly - and prefixing always sucks, IMO. It's better just to check if the real thing is there, and if not, claim it. If the final implementation ends up being called something else, it won't clash.
if(foo in "window"){
//prollyfill that sucka!
window.foo = …
}
The really bad practice I've seen is:
var foo = window.Foo || window.WebKitFoo || new Foo();
Where window.WebKitFoo is considered equivalent to some other Foo. This is what is currently screwing the Web Audio API in the wild: standardized version of WebAudio excludes/add-new-things-to Web Audio that are not in the ".WebKit" version of the API… and the ".WebKit" versions of the API are different across user agents (!).
if one was going to prollyfill WebKitFoo, then the same applies:
if(WebKitFoo in "window"){
//test behavior
if(window.WebKitFoo.methodToOverride(someTest)){
//prollyfill that sucka!
window.WebKitFoo.methodToOverride = fun…
}
};
--
Marcos Caceres
Received on Wednesday, 3 July 2013 17:48:31 UTC