Method reference conversion

[Llewellyn Falco]

I'm not sure if you guy's are aware, but there has been some amazing
working on this in the .net world by Erik Meijer, one of the creators
of Haskell.

http://msdn.microsoft.com/en-us/data/gg577609

I realize that it will be harder to create this type of fluid library
in java, because of the lack of extension methods and the need to
finalize internal variable, but even in reverse polish notion and
goofy array wrappers, this is way to powerful not to show up soon
after lambdas hit the scene.

.....

on a side note I was just thinking that the array wrapping might be
semi-nicely solved by a  Mutable class as such

public Class Mutable<T>
{
 public T _;
 public Mutable(T originalValue)
{
_ = originalValue;
}
}

then you just end up with stuff like

myVariable._ = 5;

On Sat, Jan 7, 2012 at 4:36 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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
>>
>>
>>
>



-- 
Llewellyn Falco
www.approvaltests.com
www.teachingkidsprogramming.org