Personally, I never touch the native prototypes and for homemade methods, it's ok...
But when it comes to native methods, it gets more complicated ... Indeed, how to retrieve an original state of a native prototype? This isn't possible. The idea is to have a stable solution to this deficiency Michaël Rouges - https://github.com/Lcfvs - @Lcfvs 2013/9/25 Eric Kever <lolbum...@gmail.com> > 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.rou...@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.giammar...@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.rou...@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@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > http://erickever.com > Twitter: @codeoverlode <http://twitter.com/codeoverlode> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
