Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Sun Oct 13 12:14:28 PDT 2013


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

My relative lack of experience here is probably working against me.

Would you mind explaining how WeakMaps (and later relationships) give me
that third scope parameter? Also, are you implying adding this sort of
scoped extension of a native prototype be possible/easy once those features
are implemented?

(Sending me to reading is great too, I don't want to waste your time)


On Sun, Oct 13, 2013 at 10:00 PM, Mark S. Miller <erights at google.com> wrote:

> 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/a5e6247b/attachment.html>


More information about the es-discuss mailing list