Method reference conversion

[Reinier Zwitserloot]

A while ago we did some internal research on listeners, and removeListener
was rarely getting called. As Rémi said, if you need to detach a listener
in the somewhat classic 'addListener' / 'removeListener' setup, you need to
store the ref you originally pass to 'addListener' somewhere so you can
pass it again when the time comes to call 'removeListener'.

However, this 'addListener'/'removeListener' is not actually a particularly
nice API for registering temporary listeners. This gets particularly
relevant when you run into the 'lapsed listener' problem. There are
solutions to the lapsed listener problem, i.e. adding an 'owner object' of
some sort which is carefully GC-managed via WeakReferences, and
unregistering the listener when the owner object gets GCed, the details of
which aren't relevant for lambda-dev.

My point is: I don't think "may not play well with classic 'removeListener'
methods" should not trump "makes future optimization potentially much more
difficult than it needs to be because we make promises now that we'd rather
not keep later", because removeListener itself is both rarely used and
feels, at least to me, as an anti-pattern in the first place.

 --Reinier Zwitserloot



On Fri, Dec 16, 2011 at 09:16, Rémi Forax <forax at univ-mlv.fr> wrote:

> On 12/16/2011 08:28 AM, Uther wrote:
> >> On Dec 15, 2011, at 4:10 PM, Brian Goetz wrote:
> >>
> >> Most likely outcome: no guarantees (such guarantees come with a cost)
> but it
> >> is "highly likely" that method1 == method2. When we finish the
> implementation
> >> of functional interface conversion we'll have a update.
> > So Method reference are not really suited to Listeners. I think it's a
> > shame since it was a really good use case of method reference.
>
> If you have to unregister a listener, you have to store the listener in
> a field when you create it,
> to be able to send the same reference when you unregister it.
>
> If two method reference bound to the same object share the same reference
> you need to cache them somewhere, so you create a performance tax
> everywhere you create a
> method reference and it will never scale in a threaded environment.
>
> Rémi
>
>
>