Scoped binding of a method to an object
Mark S. Miller
erights at google.com
Sun Oct 13 11:33:10 PDT 2013
Any library that monkey patches primordials and wishes to be able to rely
on the primordials being mutated only according to it should demand to be
run before primordials are otherwise corrupted or frozen, and should freeze
the primordials after patching. Of course, such a "library" isn't a library
in the traditional sense -- it is a kernel for everything loaded into that
realm after it. Two such kernels aren't composable because of this
unsolvable conflict problem.
Libraries meant to be composable should not mutate primordials, and should
assume only that primordials are in some uncorrupted state.
On Sun, Oct 13, 2013 at 11:25 AM, 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss