> Thomas Koch: > > Why does the Generator implement Supplier? I see that the get() method of > > supplier shares a lot of similarity to the build() method of a builder but > > it is semantically different, IMHO. > > > > A Supplier is meant to be given to other parts of the code and expected to > > be thread safe. A Builder is rather used locally and immediately > > discarded once the object has been built. > > > > We could introduce a Builder<T> interface if there's a need for it and one > > could even provide an Adapter that takes a Builder and exposes the > > Supplier interfaces.
> James Snell: > Renaming the Generator to Builder is fine, but I think the use of > Supplier is fine as is. Introducing a new Builder interface where the > only real difference is the name of the method to get the thing that > is built seems pointless to me. I'd like to be conservative when creating an API and not add things from which I'm not sure whether they are needed (YAGNI). So as long as there isn't a good point, why the builders should implement supplier, I wouldn't add the interface. I've found two interesting statements from Guava authors: "Actually, what I'd rather do is remove Supplier altogether. We tried to get it out before publishing the code, but ran out of time. There's no limit to the number of these generic, devoid-of-actual-meaning interfaces we could add: Predicate, Function, Supplier, Generator, Transformer, Combiner, Reducer, Procedure, BinaryPredicate, BinaryFunction, Ternary*, Builder, Factory, Callback....." http://markmail.org/message/iu6mybvofo2bcts4 "it would not be a well-behaved Supplier. [...] Just because something *can* implement an interface doesn't necessarily mean it should." http://groups.google.com/group/guava- discuss/browse_thread/thread/2558185aae955387?pli=1 Best regards, Thomas Koch, http://www.koch.ro
