Rename Genarators to Builders?

[Thomas Koch <th...@koch.ro>]

Hi,

I've seen that abdera2 seems to have introduced the Builder pattern for some 
classes, e.g. org.apache.abdera2.common.protocol.BasicWorkspaceInfo in 
common/.
However the Builder is called Generator which at first sight confused me a 
little. I know this thing as Builder Pattern[1] and it's also called Builder 
in Guava, e.g. ImmutableList.Builder().
I think it wouldn't be much work to rename it? May I?

[1] http://en.wikipedia.org/wiki/Builder_pattern

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.

Best regards,

Thomas Koch, http://www.koch.ro

Re: Rename Genarators to Builders?

[Thomas Koch <th...@koch.ro>]

> 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