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

[Joe Bowbeer]

Stream.OfInt instead of IntStream?

Do PrimitiveStreams methods become (top-level) methods in Streams?

One disadvantage of this convention is that these names are hard to
implement as extensions by 3rd parties. Suppose I need a ShortStream or a
FloatStream. Or an IntFoo for some Foo without a Foo.OfInt, then I can't
create Foo.OfInt, and IntFoo doesn't follow the naming convention.
On Dec 23, 2012 9:45 AM, "Brian Goetz" <brian.goetz at oracle.com> 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.)
>