Improving Function.prototype.bind

David Bruant bruant.d at gmail.com
Fri Jan 6 01:50:29 PST 2012


Le 06/01/2012 10:40, Andrea Giammarchi a écrit :
> if WeakMaps are so smart ... it means we cannot shim them without 
> causing leaks in non WeakMap ready browsers since no magic will 
> happen,objects as keys will simply be persistent in the WeakMap 
> private scope
Indeed. Also, Mark Miller mentionned a couple of times that the SES 
polyfill [1] leaks less than one could expect. I haven't taken the time 
to look into that but it's probably worth mentionning.

> ...does not look good, means we cannot solve this via libraries, means 
> my initial proposal is better, leaks speaking, and it uses same 
> WeakMap concept ( which to me is not new at all, check my Relator 
> function if you want, it's from years ago )
Your proposal won't be implemented in older browsers. Actually, it is 
very likely that your proposal would be implemented in browsers that 
would already have weak maps.
Under these conditions. What is the benefit of a native implementation 
rather than an WeakMap based polyfill?

David

[1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js

>
> br
>
> On Fri, Jan 6, 2012 at 10:27 AM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 05/01/2012 23:10, Andrea Giammarchi a écrit :
>>     leaks
>     When a function has no strong reference, the associated entry in
>     the first WeakMap (which is the second level of weakmap) can be GC'ed.
>     When an object has no strong reference, all entries in
>     second-level WeakMaps can be collected. I don't see any leaks.
>     Assuming a GC with reachability, each bound function is kept only
>     if both the function and the object are still in the environment
>     (which is the minimum we need to achieve the functional goal).
>
>
>>     performances
>     A native implementation can use a hash table using the 2
>     references as keys. I don't know to what extent it would be that
>     much better.
>
>
>>     as example, are the first things I have in mind when I look at
>>     that code ( assuming I understand how WeakMap works there )
>>
>>     (...)
>>
>>
>>     My point is that Function.prototype.bind is used 90% of the time
>>     with context only, 10% with arguments, 0% as different object
>>     since nobody uses two bound functions to the same object,
>>     arguments a part.
>     And you obviously have a one-year study crawling over 100,000
>     websites and 1000 node projects to back these numbers?
>
>     Also, does "use" refer to the occurence of code written doing what
>     you describe or occurence of run?
>
>     All in all, let's not use numbers or quantifiers when there is no
>     backing besides the experience of a few, because no reliable
>     decision can really be taken based on that.
>
>
>
>
>>
>>     Function.prototype.bind could have been implemented via libraries
>>     ( as Prototype did ) as well so I don't get your argument, sorry.
>>
>>     I am suggesting a semantic improvement Object related but of
>>     course I can solve all missing real-nedeed things via a library
>>     ... you know what I mean?
>     My point is that what can be solved efficiently should be by a
>     library. I think the solution I've provided would be satifactory
>     (you can obviously disagree).
>
>     I'm more interested in ECMAScript solving problems that either
>     can't be solved or not efficiently. This currently includes
>     private names, weakmaps, modules, proxies, all the syntax sugar,
>     binary data...
>
>     David
>
>
>>
>>     Regards
>>
>>     On Thu, Jan 5, 2012 at 11:01 PM, David Bruant <bruant.d at gmail.com
>>     <mailto:bruant.d at gmail.com>> wrote:
>>
>>         Hi Andrea,
>>
>>         It seems that what you want can be implemented as a library
>>         [1] (actually you did it as well in your blog post). In this
>>         gist, a cache is used. In a nutshell, it is a '(function,
>>         object) -> boundFunction' mapping. I used 2 levels of
>>         WeakMaps to achieve this.
>>
>>         I don't think a native implementation could be that much more
>>         efficient neither in space nor time.
>>
>>         Assuming my implementation does what you need, what would be
>>         the benefit of a native implementation over what I propose?
>>
>>         David
>>
>>         [1] https://gist.github.com/1567494
>>
>>
>>         Le 05/01/2012 14:54, Andrea Giammarchi a écrit :
>>>         I have thought it may be interesting to receive some comment
>>>         here too ... so here the short summary:
>>>
>>>         genericCallback.bind(sameObject)
>>>         !== genericCallback.bind(sameObject)
>>>
>>>         quite inconvenient for listeners and leading to
>>>         uncomfortable patterns ( store the bound reference somewhere
>>>         and get it back later )
>>>
>>>         plus bind, at the end of a function, where the topic is the
>>>         context, looks more like a yoda statement
>>>
>>>         "function with context as this object"
>>>
>>>         rather than
>>>
>>>         "object as context of this function"
>>>
>>>         So, the proposal, is a simplified Object.prototype.boundTo (
>>>         or eventually, to avoid conflicts with bind signature
>>>         Object.prototype.asContextOf )
>>>         where the action is object, as context, related, and the
>>>         returned function is one and one only
>>>
>>>         sameObject.boundTo(genericCallback) ===
>>>         sameObject.boundTo(genericCallback)
>>>
>>>         or, if you prefer
>>>
>>>         sameObject.asContextOf(genericCallback) ===
>>>         sameObject.asContextOf(genericCallback)
>>>
>>>         Here the whole post with better examples plus the proposed
>>>         solution that would be nice to have in JS.Next
>>>         http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html
>>>
>>>         Best Regards,
>>>             Andrea Giammarchi
>>>
>>>
>>>         _______________________________________________
>>>         es-discuss mailing list
>>>         es-discuss at mozilla.org  <mailto: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/20120106/d65ff41c/attachment-0001.html>


More information about the es-discuss mailing list