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

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.

[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