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

[Jonathan Gibbons]

I and O would be OK, I was just afraid we were headed for T, U, V, W.

-- Jon


On 11/06/2012 11:06 AM, Paul Benedict wrote:
> Is R and P better than I and O? I don't think I could guess R and P 
> without reading the javadoc. I and O, I can (no pun).
>
> On Tue, Nov 6, 2012 at 12:59 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     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 <mailto:paul.sandoz at oracle.com>> wrote:
>     >>
>     >>> On Nov 6, 2012, at 4:51 PM, Aleksey Shipilev
>     <aleksey.shipilev at oracle.com <mailto: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.
>     >>>
>     >>>
>     >
>
>
>