Hum...the closures doesn't prenvent from foreign prototyping... and all actual sorts of sandboxes are really heavy, much more than a possibly native solution, mainly about performances, like my Sandbox.js<https://github.com/Lcfvs/Sandbox.js> .
Michaël Rouges - https://github.com/Lcfvs - @Lcfvs 2013/9/25 Andrea Giammarchi <[email protected]> > in line ... > > > On Wed, Sep 25, 2013 at 11:27 AM, Michaël Rouges <[email protected] > > wrote: > >> I personally don't use libraries, I create tools and advice every day >> developers ... and it must be realistic, most don't even know what they >> include. >> > > which is why you don't want to promote a pattern that will be inevitable > abusing so that developers will have messy code and unpredictable behaviors > around because of these sort of native sandboxes in the wild. > > > > >> I remember, visiting the site of a web agency where, in the middle of the >> page, a dialog box is displayed to indicate that the webmaster had not >> paid for a license to use a jQuery plugin. >> > > > This proposal of you will never solve that problem and actually should > not/never solve that problem. > > > > >> >> So yes, I agree, it's the developer responsibility, but it would be nice that >> there is a way to do so to ensure that the tools we propose behaves >> exactly as desired, whatever the practices of the developer who uses >> them. >> >> > There are several old projects/libraries/snippets that created "extendible > natives for everyone" and that increased the mess across developers. I > wrote "Elsewhere" code, @jdalton worked on `fusejs`, many others had their > own sandbox with their extends to natives cooler than everyone else (of > course) and nobody used this stuff anyway. > > If you don't know what kind of environment you are running into you don't > use method you don't know/expect to be there while if it's about securing > your own piece of code/library there are already possible ways to guard it > inside a closure and do whatever you want in there. > > I hoe you have enough examples and background to realize this is a bad > idea that modules solved more elegantly and still you should not extend > natives if not absolutely necessary ... not even ECMAScript guys in here do > that ;-) > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
