Method Pointers

[Conrad Winchester]

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
> >
>