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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
