Scoped binding of a method to an object

Erik Arvidsson erik.arvidsson at gmail.com
Sun Oct 13 12:14:50 PDT 2013


Let's not kid ourselves. WeakMaps have bad user ergonomics and runtime
ergonomics. I think at this point non method functions are much better.
On Oct 13, 2013 3: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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131013/d1b2b4c0/attachment-0001.html>


More information about the es-discuss mailing list