hg: lambda/lambda/langtools: Added basic support for constructor references.

Alessio Stalla alessiostalla at gmail.com
Tue Jan 18 05:44:32 PST 2011


On Tue, Jan 18, 2011 at 2:23 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> On 01/18/2011 09:16 AM, Thomas Münz, XDEV Software Corp. wrote:
>
> [...]
>
>> Personally, I think for consistency with JavaDoc, the "#" should be used for java.lang.reflect.Field and java.lang.reflect.Method (btw. can't it be used in parallel, distinguished by the compiler depending on context?), but in the end, I don't care much if it will be "#" or ":" or ">" or whatever. I only know that those missing literals are a "hole" in the language, are badly needed to accomplish flexible generic frameworks and should even today be kept in mind as a much-more-needed-than-expected feature for a future language extension.
>>
>
> There is a fundamental reason why a method reference can't be a
> j.l.r.Method:
> There is a semantic mismatch: there is no corresponding j.l.r.Method to
> "hello"#length().
> j.l.r.Method represents a class file method. So no way to represent a
> partially bound function.

Well, you can't represent a partially bound method with jlr.Method,
but that doesn't mean that "hello"#length() doesn't refer to a
specific method, namely public int length() in java.lang.String. In
other words, I would find it perfectly reasonable if

Method m = "hello"#length(); would equate to Method m =
String.class.getMethod("length", int.class);

and

VoidToIntSAM x = "hello"#length(); would equate to VoidToIntSAM x =
new VoidToIntSAM() { public int whatever() { return "hello".length();
} };

Method and field references - in the context of reflection types - are
certainly outside of the scope of Lambda. That said, for future
reference, I cast my vote (of dubious value) in favor of them, because
I think they wouldn't benefit only frameworks, but users of those
frameworks as well, opening the possibility for more concise, less
error-prone use of reflection. After all, we can already write
Foo.class instead of Class.forName("com.whatever.Foo").

Just my 2 cents,
Alessio


More information about the lambda-dev mailing list