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
