Foo.Of{Int,Long,Double} naming convention (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Mon Dec 24 09:25:08 PST 2012

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 extends MutableReducer<Integer,R> { ... } interface OfLong 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121224/1a600092/attachment.html

More information about the lambda-libs-spec-experts mailing list