Function parameter order

[Tim Peierls]

Since specialized types are an ugly but necessary wart, and since often the
names won't be seen by users, it's OK to have ungainly names as long as
they are clear. I wouldn't worry too much about consistency over clarity.

So, FunctionToIntFrom<X>, FunctionFromIntTo<Y>. PredicateOfInt ... the
marker words help me understand without having to know an arbitrary rule.

--tim

On Wed, Nov 7, 2012 at 11:24 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Fair objection.  But I'm not hearing anyone proposing a consistent and
> simple way to interpret the relationship between IntFoo<T> and Foo<T,U>;
> all I'm hearing is complaining that they don't like the proposed solution.
>
>
> On Nov 7, 2012, at 11:14 AM, Tim Peierls wrote:
>
> I think you'll get *huge *resistance to these arguments from actual users
> to the point where it could seriously hamper adoption.
>
> People (regular people, that is, not language jocks) more naturally say
> things like "a function from X to Y", not "a function returning a Y and
> taking an X". Lambdas themselves are consistent with this
> inputs-then-outputs order: x -> y.
>
> People understand things mostly by analogy. There's a preponderance of
> other languages not too far removed from Java that put inputs first in
> roughly analogous settings. This is not a tangential observation; it's an
> important way to ensure that new users are immediately comfortable with the
> lambda libraries.
>
> Putting the return type ahead of the method name and parameters *is*consistent with use of the method in an assignment: public Y method(X x),
> so Y y = method(x). But that's very different from Function<X, Y> and x ->
> y.
>
> [Grumpy because no power for 9 days and new storm coming.]
>
> --tim
>
>
> On Wed, Nov 7, 2012 at 10:52 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> I think we're getting waaaaaaaaayyy too hung up on "I found another
>> library/language that does it this way."  These things are relevant
>> plus/minus considerations, but not the main consideration.
>>
>> Specialization (both primitive and arity) is a central part of the SAM
>> naming problem -- this problem is unique to our situation, so saying
>> "Library X calls it Y" is only tangentially relevant.  In any case, the
>> motivation was clearly laid out in Mike's initial e-mail: we want a
>> deterministic relationship between specializations of a SAM (IntFunction,
>> BiFunction) and its type arguments.  Considerations related to
>> specialization (such as 'this SAM name sucks when specialized', or whether
>> the speicalization prefix applies to the arg type or return type) are
>> important considerations that other languages haven't had to deal with.
>>
>> Also, note that the return-first approach is more consistent with how
>> Java declares methods:
>>
>>   public RETURN_TYPE name(ARG_TYPE) { body }
>>
>> Scala declares return/arg types in the opposite order.  So "how Scala
>> does thing X" is pretty much irrelevant in a vacuum when there are closely
>> related things it does opposite from Java.
>>
>>
>>
>> On Nov 7, 2012, at 10:06 AM, Remi Forax wrote:
>>
>> > On 11/07/2012 04:02 PM, Raab, Donald wrote:
>> >>
>> >> +1
>> >>
>> >
>> > +1 too,
>> > it seems that scala, guava and C# uses the same convention,
>> > I don't see why we should have a different one.
>> >
>> > Rémi
>> >
>> >> *From:*lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:
>> lambda-libs-spec-experts-bounces at openjdk.java.net] *On Behalf Of *Kevin
>> Bourrillion
>> >> *Sent:* Tuesday, November 06, 2012 11:59 AM
>> >> *To:* lambda-libs-spec-experts at openjdk.java.net
>> >> *Subject:* Function parameter order
>> >>
>> >> It sounds as though we're planning on Function<ReturnType, InputType>.
>> >>
>> >> I'd just like to note that this is going to put codebases that are in
>> any stage of migration to JDK types from existing libraries including Guava
>> in a really, really bad position.
>> >>
>> >> Every time I see Function<A, B> for /years/, I am going to have to
>> check the imports to find out whether that's A->B or B-A.
>> >>
>> >> I'm not saying this consideration should trump all others. Just noting
>> that I see this as a very bad problem for my user base.
>> >>
>> >> --
>> >>
>> >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com<mailto:
>> kevinb at google.com>
>> >>
>> >
>>
>>
>
>