Method Pointers

[Ted Neward]

That would be tricky; under the covers, a Delegate is a wrapper around a
metadata token (the primary key in to the relational table in which all .NET
metadata is stored, in contrast to the tree structure of .class files), so
it's easy to compare the metadata tokens. Lacking any sort of primary key in
the .class files, the JVM is back to the problems that Brian mentioned
earlier.

I suppose the compiler could generate a GUID for every method in every class
and stick it into the .class file as a runtime-accessible annotation, but
Lord help us, that would be a lot of overhead to pay for this feature that I
think most people would never use...

I would have to agree with Brian, I think the right answer here is for the
developer smart enough to think to store a List of method pointers to know
(via Google search, if necessary) that method pointers don't provide
identity semantics and provide her own when she needs it....

Just my $.02 worth....

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

> -----Original Message-----
> From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-
> bounces at openjdk.java.net] On Behalf Of Vitaly Davidovich
> Sent: Sunday, February 26, 2012 5:37 PM
> To: Brian Goetz
> Cc: lambda-dev
> Subject: Re: Method Pointers
> 
> 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
> > >
> >
> >