ES Native Mode proposal

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Sep 25 15:23:27 PDT 2013


it does give you private constructors ... so you can retrieve them via your
Sandbox library, as example, and do all crazy things you want including
refixing surrounding env if needed ... ^_^

Also, since you wrote that library, you already know that having new
natives all over is not good for anyone, right? ;-)


Last, but not least, don't freeze natives if not necessary 'cause you might
end up unable to have normal behaviors.

A classic example: `Object.freeze(Object.prototype);` then later on no
class will be able to have a `toString` method redefined in its proto if
not passing through `Object.defineProperty`

A library of mine that works defensive in such direction is redefine.js
while the most handy, the one I prefer, is again the one that add 4 methods
to the `Object.prototype` in a non enumerable way so you daily JS code
won't be affected ^_^ (hasOwnProperty will be false and for/in are not
affected ... how lovely)

Good luck though with possible solutions :-)







On Wed, Sep 25, 2013 at 2:16 PM, Michaël Rouges <michael.rouges at gmail.com>wrote:

> 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 <andrea.giammarchi at gmail.com>
>
>> 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
>>> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/943efad1/attachment-0001.html>


More information about the es-discuss mailing list