Method Pointers

[Brian Goetz]

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
>