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 <[email protected]>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 <[email protected]> > >> 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 <[email protected] >> > 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- http://erickever.com Twitter: @codeoverlode <http://twitter.com/codeoverlode>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
