Improving Function.prototype.bind

David Bruant bruant.d at gmail.com
Fri Jan 6 07:23:27 PST 2012


Le 06/01/2012 12:51, Andrea Giammarchi a écrit :
> unreachable without reference count? do you have an example different 
> from a private scope object that is reachable from that scope so I 
> would not call it unreachable?
I'm not sure I understand your question.
In IE6 (7? 8?), written naively, event handlers often had a reference to 
the element they were bound to (via scope chain) and the element had a 
reference to the handler (obviously). It created a cycle that reference 
counting based GC was unable to collect.
Mark-and-sweep GCs don't have this problem at all. It doesn't prevent 
every memory leak (no GC can), but is far more efficient in obvious 
cases than reference counting.

> In any case I understand your leaks point and if WeakMap solves this, 
> but I strongly believe no shim will be able to emulate this behavior, 
> no matters how much articulated the implementation is ( taking that 
> google shim as example that also won't work as it is in older browsers 
> in any case )
Yes, in older browser, any implementation of what you want would leak in 
some cases.

> Then this is a dead line, something that you said makes sense as 
> problem, won't be solved natively because it can be implemented via 
> libraries ... but if this is the logic, I wonder what is ES5 about 
> with all its extras ( Array, Function, String, etc )
I would guess uniformisation of very frequent patterns (forEach, map, 
filter...), a need for a reliable isArray method that some libraries got 
right and other completely wrong.
ES5 was far more that these shimable extras: strict mode, fine grained 
property control, getters/setters to name a few.
There was probably also some "evangelisation" or "politics". Take 
Object.create. Besides the second argument, it can be shimed. Yes, but 
having this fundamental construct also helps a lot in understanding and 
teaching the language.

Also, I did not say that everything that can be done with a library 
should not be part of the language. I'm in priority interested in seeing 
in the language things that cannot be done (at all or efficiently) with 
a library. That's just a priority (of mine, by the way. I haven't seen 
an expression of TC39, but the current list of proposal speaks for 
itself, I think)
It seems that it has been in JavaScript from the beginning that the 
language provides basic bricks and people can feel free to create 
themselves what they want/need on top of that.

Some patterns were very common and have later been integrated into the 
language.
Some functions could probably be made far more efficient or reliable 
when integrated in the language.

I think that bringing in the language things that can be implemented in 
libraries should be justified by more than a use case. For instance, I'm 
enthusiastic of promises [1], these are more and more used, there are a 
lot of different APIs. It will be interesting to see what wins and bring 
this to ECMAScript when it seems promises have been "explored".

But I still don't see a strong justification in a memoized bind. I 
understand and agree with the use case, but it doesn't seem enough to 
bring it into the core language (and you haven't answered the security 
concern raised by Mark...)

David

[1] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency


More information about the es-discuss mailing list