Method Pointers

Ted Neward ted at
Fri Mar 23 18:22:23 PDT 2012

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



From: neal.gafter at [mailto:neal.gafter at] On Behalf Of Neal
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> 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


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


More information about the lambda-dev mailing list