Method Pointers

[Ted Neward]

Very true! Hadn't thought about that. I was thinking the more pedestrian
case where Foo() will be a singular mdtoken, not the lambda case. You're
closer to the subject than I, Neal, but I thought I heard a C# team member
tell me, though, that they were trying to optimize your case at the compiler
level, so that a1 and a2 would, in fact, be considered identical, since the
lambda used would in fact be "folded" down into a single method (since they
contain the same contents). Not so?

 

Ted Neward

Java, .NET, XML Services

Consulting, Teaching, Speaking, Writing

http://www.tedneward.com

 

 

From: neal.gafter at gmail.com [mailto:neal.gafter at gmail.com] On Behalf Of Neal
Gafter
Sent: Friday, March 23, 2012 1:02 PM
To: Ted Neward
Cc: Vitaly Davidovich; Brian Goetz; lambda-dev
Subject: Re: Method Pointers

 

On Thu, Mar 22, 2012 at 11:15 PM, Ted Neward <ted at tedneward.com> wrote:

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 think we're imagining that .NET gives us more than it actually does.  The
fact that two .NET delegate objects have distinct metadata tokens gives you
no information as to whether or not they represent the same underlying
lambda expression.  So .NET isn't in much better shape.  Specifically, the
following snippet of C# code prints "False":

 

        System.Action a1 = () => { };

        System.Action a2 = () => { };

        System.Console.WriteLine(a1.Method == a2.Method);