Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Sun Oct 13 11:29:29 PDT 2013


David Bruant <bruant.d at 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 <bruant.d at gmail.com> wrote:

>  Le 13/10/2013 20:03, Benjamin (Inglor) Gruenbaum a écrit :
>
>      David Bruant <bruant.d at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/89fd3a85/attachment-0001.html>


More information about the es-discuss mailing list