Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
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
problem?


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
>> 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/f5bcb846/attachment.html>


More information about the es-discuss mailing list