ES Native Mode proposal

Eric Kever lolbummer at gmail.com
Wed Sep 25 11:45:15 PDT 2013


I'm no real expert here, but this seems like a proposal for a workaround
for messy code rather than something that's actually necessary within the
language.


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.
>
> 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
>>>
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
http://erickever.com
Twitter: @codeoverlode <http://twitter.com/codeoverlode>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130925/444c8992/attachment.html>


More information about the es-discuss mailing list