ES Native Mode proposal

Michaël Rouges michael.rouges at gmail.com
Wed Sep 25 11:27:08 PDT 2013


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.

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.

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.

No?

Michaël Rouges - https://github.com/Lcfvs - @Lcfvs


2013/9/25 Andrea Giammarchi <andrea.giammarchi at gmail.com>

> it's like bringing realm all over in any part of any piece of code ... a
> road to hell for interoperability and/or security.
>
> I think you don't really want to:
>
>   1. include any jurassic JS library that has no reason to be used in
> current JS status
>   2. be sure that libraries that extend native constructor do that for
> good reason and most likely will never conflict with any API
>
> Point one is because there are not many lib out there these days that
> pollutes global native prototypes but I have one, called eddy, that does
> not conflict with anything and set configurable and writable properties,
> but not enumerable, in a way everybody expect them to behave (de-facto
> EventEmitter standard)
>
> Not a single library, neither in node.js, ever had a conflict or problem
> with that ^_^
>
> As summary: choose your libraries carefully. That will do a much better
> job than your proposal.
>
> my 2 cents
>
>
>
>
> On Wed, Sep 25, 2013 at 8:41 AM, Michaël Rouges <michael.rouges at gmail.com>wrote:
>
>> Hi all,
>>
>> Given the number of scripts from various sources that may be contained in
>> a web page, there may be prototyping conflicts.
>>
>> To solve this, heavy techniques are often used, such as iframes, to execute
>> code in peace.
>>
>> I'm often thinking it might be much easier to tell the browser to have a
>> native to a given context, incidentally, to the functions from this
>> context & nested, regarding on the last relative scope with this
>> instruction.
>>
>> What I suggest, therefore it is a complementary mode to `'use strict'`...
>> the `'use native'`.
>>
>> Suggested behavior :
>>
>> `Object.prototype.serialize = function serialize() {
>>     // serialization code
>> };
>>
>> (function () {
>>     'use strict', 'use native';
>>
>>     Object.prototype.hasOwnProperty('serialize') // false
>>
>>     Object.prototype.serialize = function serialize() {
>>         // serialization code
>>     };
>>
>>     (function () {
>>         Object.prototype.hasOwnProperty('serialize') // true
>>     }());
>>
>>     (function () {
>>         'use native';
>>
>>         Object.prototype.hasOwnProperty('serialize') // false
>>     }());
>> } ());`
>>
>> Thanks in advance for your advices.
>>
>>
>> Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
>>
>> _______________________________________________
>> 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/0c83cb6a/attachment-0001.html>


More information about the es-discuss mailing list