Method Pointers

[Gregg Wonderly]

It seems to me that it would be probable that anyone holding a this#method reference would at some point use it for a membership test/expression.  I think that in the case of an InvocationHandler, in particular, that the method would be of interest and possibly used to key to other data. If there is no constant representation, it seems very problematic to me.

Gregg

Sent from my iPhone

On Feb 26, 2012, at 4:30 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
>> 
>