David Bruant <bruan...@gmail.com> wrote > This proposal does not aim at solving the problem of library conflicts which existed before this proposal and should be solve independently.
Of course, and I'm sorry if I implied otherwise. I'm sure we all acknowledge the problem of extending the native prototypes in libraries. I just don't understand how having a `_` prefix attempts to give us a solution to the problem. I'm not saying I have a solution either, but I think implying that it's ok to extend them with a prefix doesn't really solve much. Maybe I got what you were trying to say wrong though. On Sun, Oct 13, 2013 at 9:25 PM, David Bruant <bruan...@gmail.com> wrote: > Le 13/10/2013 20:03, Benjamin (Inglor) Gruenbaum a écrit : > > David Bruant <bruan...@gmail.com> wrote: > > Concretely, attempted prolyfills, could be _-prefixed (that really > fits with what you call "poor-man's prefixing", I believe) > > Authors would feel free to add something like Array.prototype._shuffle > or Array.prototype._last, or EventTarget.prototype._on without worrying > about collision with the platform. > > What if I use two libraries that polyfill `_shuffle` or `_last` > differently (let's say with different behavior for an empty array for > `_last` or weaker guarantee on the randomness in `_shuffle`)? > > What do you do today when a library overrides Array.prototype.concat with > a different semantics? > What do you do when you load two libraries each defining a global $ with > different semantics? > > Apply every prevention/resolution mechanism you use today with global > properties. Among other ideas: > * don't load libraries that are known to have conflicts (!!) > * isolate the code that enhance built-ins (preferably, run it before > anything else and not in the middle of your application lifecycle) > * Define functions as non-configurable/non-writable in development mode to > discover conflicts before pushing to production. > > This proposal does not aim at solving the problem of library conflicts > which existed before this proposal and should be solve independently. > > David >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
