Scoped binding of a method to an object
Mark S. Miller
erights at google.com
Sun Oct 13 12:00:10 PDT 2013
On Sun, Oct 13, 2013 at 11:36 AM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> wrote:
> First of all - well put.
> Second, wouldn't being able to do this in a scoped way solve the conflict
As Brendan points out, doing this in a "scoped" way adds a third parameter
representing the scope, or that somehow needs to be scope specific. Such a
third parameter needs to be first class. WeakMaps and relationships do
> On Sun, Oct 13, 2013 at 9:33 PM, Mark S. Miller <erights at google.com>wrote:
>> 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
>>> 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