Functional interface confusion

Nick Williams nicholas+openjdk at nicholaswilliams.net
Sun Jul 7 09:24:26 PDT 2013


On Jul 7, 2013, at 6:25 AM, Remi Forax wrote:
> On 07/07/2013 11:25 AM, Stephen Colebourne wrote:
>> 
>> 
>> Secondly, I would prefer that this was valid as a way to resolve the problem:
>> static <T extends Temporal> TemporalAdjuster firstDayOfMonth() {
>>  return (T temporal) -> (T) temporal.with(DAY_OF_MONTH, 1);
>> }
> 
> Casting is never the right incantation when you have trouble with 
> generics :)
> 
> The syntax should be something like this:
>   (<T extends Temporal> T temporal) -> temporal.with(DAY_OF_MONTH, 1);
> otherwise the compiler doesn't know if T is declaration of a type 
> parameter or
> a type variable declared before.
> 
> So this syntax is not natural and chance to discover it by yourself is 
> close to 0.

vvv

On Jul 7, 2013, at 9:28 AM, Brian Goetz wrote:
> Its OK to be sad about this, but there really isn't a credible 
> alternative short of inventing a syntax for generic lambdas, which we 
> didn't want to do.

vvv

The chance of discovering a generic syntax by yourself being close to 0 is nothing new in Java. I'm not complaining, I'm just stating a fact. There are several things that I never would have discovered myself and only learned by /reading the documentation/. For example:

public <T extends Something> T doSomething(Class<T> clazz) { … }

Arrays.<Something>asList();

I didn't guess these. I learned them through reading. IMO, there's nothing wrong with new syntax requiring reading. Languages evolve and sometimes that evolution introduces new syntax. There's nothing wrong or unnatural about that, and it is expected (in my mind) to have to read something to learn it. Most developers can't just magically divine the syntax of a language without some kind of guide.

So I'm not necessarily suggesting that we should proceed with new syntax (I'm also not saying we shouldn't), I'm just saying I don't buy into the reasons put forth for not doing so.

Nick


More information about the lambda-dev mailing list