Heads up: Mapper<T, R> -> Mapper<R, T>

[Jonathan Gibbons]

Can I suggest that we at least try and establish some naming convention 
as well, so that we are not just relying on positional conventions.

There are already some JDK APIs with "result first, then parameter", 
using the convention   Name<R, P>   R for Result, P for Parameter

-- Jon



On 11/06/2012 10:36 AM, Remi Forax wrote:
> On 11/06/2012 06:20 PM, Sam Pullara wrote:
>> Neither Scala nor Guava makes this ordering choice. Let's not be innovative
>> where it doesn't matter and will only cause confusion.
>>
>> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Function.html
>> http://www.scala-lang.org/api/current/scala/Function1.html
>>
>> Sam
> I don't care about the order we choose if it's the same everywhere :)
> For the record, C# uses the same order too.
>
> http://msdn.microsoft.com/en-us/library/bb397687.aspx
>
> Rémi
>
>> On Tue, Nov 6, 2012 at 8:10 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com>
>>> wrote:
>>>
>>>> On 11/06/2012 10:42 AM, Paul Sandoz wrote:
>>>>> To align better with EG discussions some nominal function types, such
>>>>> as Mapper/FlatMapper, were modified such that the type parameter for
>>>>> the return type is declared first rather than last.
>>>> And the rationale for Combiner<W, T, W> -> Combiner<W, W, T> in the
>>>> reduceBy is the same?
>>>>
>>> Yes, that change is the result of refactoring the type parameter order on
>>> Combiner:
>>>
>>>
>>> http://hg.openjdk.java.net/lambda/lambda/jdk/diff/e60b1819b652/src/share/classes/java/util/functions/Combiner.java
>>>
>>> i.e. the last type parameter, W that is the result type, is shuffled up to
>>> become the first.
>>>
>>> Paul.
>>>
>>>
>