Fun with method references

[Brian Goetz]

> If you do that, you will not be able to introduce function type later !

But we are already there with Runnable, Callable, Comparator, etc.  Any lambda 
strategy must deal with SAM types in a happy way; the world is full of SAM-ful 
interfaces.

If you are saying that we are likely to make the problem worse before we make 
it better, that may be so.  But there are two possible futures:
  - SAM types only
  - SAM types living side-by-side with function types

The third possibility, "function types only", expired in 1996.

You are absolutely right that the language part of this exercise is small 
compared to the libraries part.  We are anxious to get on to that part of the 
program.


>
> In my opinion, I will be happy if
> 1) you don't introduce such API now.
> 2) you introduce them and show how they can be retrofit to use function
> type.
>
> I have another fear. The introduction of lambda in C#
> has shown that the API to deal with them is really huge.
> You need more than a year to have a polished version of such API.
>
> Rémi
>
>> On 8/4/2010 5:45 PM, Paul Benedict wrote:
>>
>>> Do you think JDK 7 will come with new utility SAM interfaces? I am sure
>>> there are other common patterns throughout Java that could be SAM-ified.
>>>
>>> On Wed, Aug 4, 2010 at 4:33 PM, Brian Goetz<brian.goetz at oracle.com
>>> <mailto:brian.goetz at oracle.com>>   wrote:
>>>
>>>       Check this out -- this works with the latest prototype:
>>>
>>>       interface Extractor<T, U>   {
>>>            public U get(T t);
>>>       }
>>>
>>>       class Arrays {
>>>            public<T, U extends Comparable<? super U>>
>>>            void sortBy(T[] array, Extractor<T, U>   extractor) { ... }
>>>       }
>>>
>>>
>>>       String[] strings = ...
>>>       Arrays.sortBy(strings, String#length);  // sort strings by length
>>>
>>>       Foo[] foos = ...
>>>       Arrays.sortBy(foos, Foo#getA);          // sort by JavaBean property A
>>>
>>>
>>>
>>>
>>>
>>
>
>