abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Koch <tho...@koch.ro>
Subject Re: Rename Genarators to Builders?
Date Sat, 28 Jan 2012 16:08:51 GMT
> 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 
> > 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 

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....."

"it would not be a well-behaved Supplier. [...] Just because something *can* 
implement an interface doesn't necessarily mean it should."

Best regards,

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

View raw message