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.
>

Thanks.


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

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
exactly that.



>
>
> 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
>>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/05d45585/attachment.html>


More information about the es-discuss mailing list