Method Pointers

[Howard Lovatt]

When using inner classes in my own code I have used compare by value, including bound variables, rather than by location. This has worked well for me. Is it a possibility for lambdas?

  -- Howard Lovatt +61 419 971 263 (sent from my PDA)

On 27/02/2012, at 6:54 PM, Conrad Winchester <conrad at dz015.com> wrote:

> Have to agree with Vitaly here, I think the SAM implementation should allow for equality or a different approach taken.
> 
> I think that this lack of equality is a shame, because
> 
> 1) other languages have dealt with this without this level of confusion.
> 2)  it will cause the community to be plagued with exactly the same question over and over again - it feels like an incomplete implementation of method pointers.
> 3) as was stated in the other thread it makes the use of method pointers as listeners almost completely useless.
> 
> I think it would be good, that if equality is not guaranteed, then we should have at least some test for 'sameness'.  There may be some light - I noticed in my intellij debugger that the method pointer has two fields that in it rec$ and this$0. I was able to use these (in the debugger) to see that I could tell the difference between two different instances having pointers to the same method, but they are not accessible from the language to implement an equals() method - is this in the works?
> 
> Conrad Winchester
> 
> 
> On 27 Feb 2012, at 01:37, Vitaly Davidovich wrote:
> 
>> Brian, has there been any discussion to follow the .Net model where lambdas do have identity equality? They achieve this by having method references/pointers as proper types in the type system (i.e. System.Delegate).  I can see how this is more involved than what java closures are, but perhaps it's the "right" thing to do?
>> 
>> Sent from my phone
>> 
>> On Feb 26, 2012 5:32 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>> Good question.  Agreed that all things being equal, this would be a
>> desirable property.
>> 
>> Unfortunately, guarantees like this come with a possibly significant
>> cost, and the question comes down to: how much are we willing to pay for
>> properties like this?
>> 
>> Where things are currently is that the identity properties of SAM
>> conversion are deliberately underspecified, to maximize flexibility /
>> minimize costs for the runtime.  The current implementation makes some
>> attempts to fold together identical method references and lambdas, but
>> does not make "heroic efforts" to do so.
>> 
>> If you want identity equality for bound method references (this::name),
>> this turns out to be extremely expensive; we would have to keep an
>> interned table of captured "method m bound to receiver r" method
>> references, using weak references to keep this table from causing memory
>> leaks.  Are we willing to pay that much in capture cost, implementation
>> complexity, and dynamic footprint to preserve the property you are
>> asking for?  (This seems a pretty clear "no" to me; this is one of those
>> properties that provides a small benefit for a few but a significant
>> cost for everyone.)
>> 
>> One weaker and less expensive option would be to provide this guarantee
>> for unbound and static references only (though this is by no means
>> free); another would be to commit only to making the two objects .equals
>> to each other rather than identity-equals.  This is under consideration,
>> but even this may be cost-prohibitive and/or too full of holes to
>> provide a sufficiently intuitive semantics to make it worth it.
>> 
>> (Aside: computational physics tells us that in the general case, this
>> problem is undecidable anyway (see Rice's theorem), so whatever we did
>> would necessarily be limited, and its limitations might be surprising
>> enough that it would be better to promise nothing than to promise
>> something complicated and confusing.)
>> 
>> 
>> On 2/26/2012 4:49 PM, Conrad Winchester wrote:
>>> Hi all,
>>> 
>>> I'm getting a little confused about closures and lambdas - I originally posted this question to closures-dev, but somebody told me that that was the wrong list and the lambda-dev is the right list. To me this question crosses both concepts - anyway
>>> 
>>> my name is Conrad Winchester and I am a long time developer. I am currently experimenting with the new lambdas and function pointers in the Java 8 developer preview. I have come across something that strikes me as a little inconsistent in the current way that they are handled and just wanted to see what other people think. I will try to be succinct:
>>> 
>>> I wish to add and remove function pointers to collections. I refer to the functions using a this reference. Essentially the issue is this. If I use
>>> 
>>> collection.add(this#methodName)
>>> 
>>> then I can not use
>>> 
>>> collection.remove(this#methodName)
>>> 
>>> because the reference 'this#methodName' is different to the first one. I think this is due to the way that SAM interfaces are used to wrap the closures.
>>> 
>>> A side effect of this is that this will return false
>>> 
>>> public boolean checkConsistency()
>>> {
>>>      SomeSAMInterface m1 = this#methodName;
>>>      SomeSAMInterface m2 = this#methodName;
>>>      return m1==m2;
>>> }
>>> 
>>> I personally think that every time I use 'this#methodName' it should return the same reference. Is this correct?
>>> 
>>> Are there any plans to make method pointers always point to the same thing. If not it makes it much more awkward to use them
>>> 
>>> 
>>> Thanks
>>> 
>>> Conrad Winchester
>>> 
>> 
> 
>