Method Pointers

[Vitaly Davidovich]

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