> Greg, you didn't detail many of the "number of issues" with WeakReferences,
Most of them are related to different approaches we might take to support weak references - I left them out because there are other stronger arguments against weak references and didn't want to muddy the rest of the email. > in my experience WeakReferences > are better since the lifecycle of the listener is generally (90%+) > equivalent to the lifecycle of the component that defines the listener. I mentioned this in my previous email, and I think it is actually a much stronger argument for strong references: In this case, you don't need to worry about unregistering the listener anyways, so weak references add almost no value. > One issue mentioned is the use of an anonymous inner class (a questionable > pattern anyway) Anonymous inner classes are not a questionable design pattern. They have a valid use case in event handling, also described in my previous email. Once you get used to the syntax (which I'll admit seemed a bit strange at first), they become quite useful. To me, they are somewhat akin to closures, which also seemed strange at first but are the cornerstone of many currently popular languages. > when annotations are available users generally use that > more terse route rather than using an anonymous class. I am not familiar with techniques for using annotations to replace anonymous inner classes. Can you provide some examples? > I think the encapsulation argument is extremely weak. Firstly, most UI > developers don't care too much about building extensible classes It's not a question of extensibility - it is about method visibility. When your class implements an interface, all listener methods by necessity become public. Any other class can now invoke the listener method, effectively spoofing the event. This is a poor design that inner classes allow you to avoid. Also, if your class needs to respond to multiple events, it must now implement multiple interfaces. This further bloats its public API and exposes it to additional misuse. > Lastly, if you don't like that idea, you can easily create private fields > that are listeners. I'm not sure how you could do this without inner classes.
