Function type naming conventions

[Howard Lovatt]

The method I have found concise and unambiguous is to mimic the generic arguments of the base interface:

Function<I, O> // I -> O
FunctionTI<I> // I -> Int
FunctionIT<O> // int -> O
FunctionII // int -> Int

Also note that it is an advantage to have all the 'Functions' begin with Function so that they are listed together in Javadocs. 

I have a preference for I and O for the generic arguments because that is the commonly used abbreviation for input and output, whereas T seem totally arbitrary and conveyed no useful information. R is OK but it is hard to think of a good match for the input. 

  -- Howard. 

Sent from my iPad

On 12/01/2013, at 4:37 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 01/11/13 12:28, Dan Smith wrote:
> 
>>>> IntValFunction<T> // T -> int
>>>> 
>>>> The meaning should be unambiguous.
>>> 
>>> Only if you mentally associate "val" with the result :-)
>> 
>> What I'm hoping to contribute is that, beyond just "I like the way
>> IntValFunction sounds," the established mathematical terminology IS
>> "integer-valued function."  If we can express that concisely, then the name
>> says exactly what the type means, without having to invent a new term or fall
>> back to the more verbose "function from integer to object."
> 
> I'm really not trying to be hostile about this, but just noting that
> the programmer impact of these suggestions relies on common
> shared conventions/intuitions, but since there currently are none
> in Java, clarity seems to be the primary goal.
> 
> (As evidence, consider discussions of method "fun1.compose(fun2)".
> Which way does it go? Probably best to have no method just
> named compose.)
> 
> -Doug
>