ES Native Mode proposal
andrea.giammarchi at gmail.com
Wed Sep 25 13:56:12 PDT 2013
in line ...
On Wed, Sep 25, 2013 at 11:27 AM, Michaël Rouges
<michael.rouges at gmail.com>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
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 ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss