Foo.Of{Int,Long,Double} naming convention

[Brian Goetz]

There are two things here:
  - Do we need separate interfaces
  - Does this naming convention make sense

The naming convention was proposed as a means of reducing the perceived 
surface area in cases where separate interfaces are needed.

There are definitely cases where separate interfaces are needed.  For 
example, Iterator.  If we have a stream of ints, we need some way to ask 
for the ints without boxing.  This could be PrimitiveIterator.OfInt, 
IntIterator (Interator?), IntCursor, etc.  So this thread is mostly 
about "If we do find ourselves needing separate interfaces, what should 
we call them."

Separately, we have been trying to not specialized when we can get away 
with doing so.

On 12/31/2012 2:24 AM, David Holmes wrote:
> Does this really buy enough to make distinct interfaces worth their weight?
>
> David
>
> On 24/12/2012 3:44 AM, Brian Goetz wrote:
>> For types that have primitive specializations that are subtypes of the
>> base type (e.g., MutableReducer), we've been converging on a naming
>> convention that puts the subtypes as nested interfaces. For example:
>>
>> interface MutableReducer<T,R> {
>>
>> // reducer methods
>>
>> interface OfInt<R> extends MutableReducer<Integer,R> { ... }
>> interface OfLong<R> extends MutableReducer<Integer,R> { ... }
>> }
>>
>> The motivation here is (a) reduce the javadoc surface area, (b) groups
>> related abstractions together, (c) makes it clear that these are
>> subsidiary abstractions, and (d) keep the cut-and-paste stuff together
>> in the code. The use site also looks pretty reasonable:
>>
>> class Foo implements MutableReducer.OfInt { ... }
>>
>> This shows up in Sink, IntermediateOp, TerminalOp, MutableReducer,
>> NodeBuilder, Node, Spliterator, etc. (It also shows up in concrete
>> implementation classes like ForEachOp, MatchOp, and FindOp, though these
>> will not be public and so (a) doesn't really apply to these.)
>>
>> Are we OK with this convention? It seems to have a tidying effect on the
>> codebase, the documentation, and client usage, and mitigates the pain of
>> the primitive specializations. (There will be grey areas where its
>> applicability is questionable; we can discuss those individually, but
>> there are a lot of things that it works for.)