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

[Brian Goetz]

That is the most likely suspect.  Which would then want that the type of 
a method reference be jlr.Method, which is problematic because Lambda 
wants method references to be SAM-converted (just as lambda expressions 
are.)  At which point I say "ugh, how did we get here?" and start 
looking for backtrack paths.

<observation>
Jumping up a level, this illustrates the dark side of the (almost always 
specious) "consistency" argument**, which in this case goes like:

  - If you have method references, you should have field references, for 
consistency
  - The obvious type of a field reference is jlr.Field
  - Therefore for consistency, the type of a method reference should be 
jlr.Method
  - We want method references to be SAM-convertible, just like lambdas
  - Since the type of a method reference is jlr.Method, I guess we need 
a conversion from jlr.Method to SAM
  - There have been other requested conversions, e.g., 
lambda-to-MethodHandle.  So for consistency I guess we want a conversion 
from jlr.Method to MethodHandle too?  And back?
  - Cycles in conversions are great feeding grounds for puzzlers.

You see where this goes.  You start pulling on a string, and before you 
know it you have reduced your sweater to a messy lump of string.

**This is not to say that consistency is not good, but the reality is 
that the language is already full of inconsistency and therefore 
consistency can't actually be achieved, and all we can do is choose 
where we want our inconsistencies.  But we can justify nearly any 
feature we happen to want by saying "for consistency!", because you can 
usually find some other feature with which it is consistent.  And 
therefore it is a very weak argument (on its own) for including a 
language feature.
</observation>

Which brings me back to the original discussion: method references are 
useful for lambda.  Field references, on the other hand, have very 
little contribution to lambda, and also have the major defect that they 
are really a completely different beast from method references, and 
therefore the implicit "member reference" concept (which seems like an 
obvious unifying abstraction) turns out to be a false abstraction.



On 1/17/2011 1:37 PM, Paulo Silveira wrote:
> 2011/1/17 Rémi Forax<forax at univ-mlv.fr>:
>> On 01/17/2011 06:56 PM, Brian Goetz wrote:
>>> If you mean field references, yes, this was already discussed.  It was
>>> decided that this was outside the scope of Lambda.
>>>
>>> (question for you to think on: what would the type of a field reference
>>> be?)
>>
>> java.lang.Property but that's another story.
>
> why not plain old java.lang.reflect.Field if a new property syntax is
> not possible?
>
> thanks
>
>>
>> Rémi
>>
>>>> This  has probably  been discussed already, but since there are
>>>> Methods and Constructor references, any chances to have Attribute
>>>> references?
>>>>
>>>> Paulo
>>>>
>>>> --
>>>> Paulo Silveira
>>>> Caelum | Ensino e Inovação
>>>> www.caelum.com.br
>>>> www.arquiteturajava.com.br
>>>>
>>>>
>>>>
>>>> 2011/1/17 Rémi Forax<forax at univ-mlv.fr>:
>>>>>     Cool !
>>>>>
>>>>> Rémi
>>>>>
>>>>> Le 17/01/2011 15:36, maurizio.cimadamore at oracle.com a écrit :
>>>>>> Changeset: 9a616df38d88
>>>>>> Author:    mcimadamore
>>>>>> Date:      2011-01-17 14:34 +0000
>>>>>> URL:       http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9a616df38d88
>>>>>>
>>>>>> Added basic support for constructor references.
>>>>>> Syntax is as follows:
>>>>>>
>>>>>> ClassName [optionalTypeArgs] '#' 'new' [optionalArgs]
>>>>>>
>>>>>> Examples:
>>>>>>
>>>>>> Foo#new ->       (*)Foo [most specific constructor]
>>>>>> Foo#new() ->       ()Foo
>>>>>> Foo#new("Hello!") ->       (String)Foo
>>>>>> Foo<String>#new("Hello!") ->       (String)Foo<String>
>>>>>>
>>>>>> ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>>>>>> ! src/share/classes/com/sun/tools/javac/comp/Lower.java
>>>>>> ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
>>>>>> + test/tools/javac/lambda/MethodReference17.java
>>>>>> + test/tools/javac/lambda/MethodReference18.java
>>>>>> + test/tools/javac/lambda/MethodReference19.java
>>>>>> + test/tools/javac/lambda/MethodReference20.java
>>>>>> + test/tools/javac/lambda/MethodReference20.out
>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>>
>>
>