Le 27/07/2013 20:27, Brendan Eich a écrit :
Weak refs are necessary for observer patterns, as we've discussed ad
nauseum.
That's not the conclusion I took from these discussions. As I feel words
are important, the conclusions I took are:
WeakRefs are *necessary* for distributed acyclic garbage collection.
They are only *convenient* for observer patterns: people can always
unsubscribe their listeners or use another equivalent ".dispose()
protocol" (assuming the API has been thought with that in mind which it
is not always).
While ".dispose() protocols" are manual, explicit and always
developer-initiated, WeakRefs are a uniform equivalent mechanism that is
most often implicit (goes with the natural flow of programming, no need
for explicit APIs) and GC-initiated (so half-automated and automated
only in the cases the GC starts the cascade by breaking references).
There is a consensus that the convenience is so important that it is
*felt* as necessary and alone justifies the inclusion of WeakRefs.
Do you agree on this conclusion?
Sorry for re-hashing the same things over and over, but I feel it's
important that people don't start thinking that WeakRefs are a
silver-bullet that is *necessary* for memory management (in
one-memory-space programs). It's already hard enough to make people stop
talking about cycles anytime someone brings up garbage collection! (I'll
happily answer questions on this topic off-list to anyone in doubt :-) )
On a related note, I recently had an experience writing an addon and
using an API where the listener was held weakly by default [1]. It took
me some time to understand why my function (passed as "inline" function
expression) was called only once... (granted, I should have read the doc
more carefully. From the examples I read, I imagined the boolean was
like the 3rd addEventListener argument. Another instance of the boolean
trap [2] I guess).
Anyway, the JS habit of writing "inline" function expressions as event
listeners isn't very compatible with weak listeners.
I don't think we're going to reject them just because of potential
observable closure-optimization interop breaks.
This optimization or another one. But fair enough; I just wanted to
bring up the "threat" for evaluation.
David
[1]
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/system/events.html#on%28type%2C%20listener%2C%20strong%29
[2] http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
