Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at
Sun Oct 13 11:36:53 PDT 2013

First of all - well put.

Second, wouldn't being able to do this in a scoped way solve the conflict

On Sun, Oct 13, 2013 at 9:33 PM, Mark S. Miller <erights at> 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>wrote:
>>  Le 13/10/2013 20:03, Benjamin (Inglor) Gruenbaum a écrit :
>>      David Bruant <bruant.d at> 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 at
> --
>     Cheers,
>     --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list