commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [CSV] Should the Builder API be optional?
Date Tue, 09 Apr 2013 05:22:33 GMT
WRT org.apache.commons.csv.CSVFormat.CSVFormat(char, Character, Quote,
Character, Character, boolean, boolean, String, String, String[])

There does not seem to be a good reason why this is not public. The only
argument I've heard is that some people do not like to use long ctors. But
so what? If we make it public, users have the choice to the the whole
fluent builder API or not.

Thoughts?

Gary


On Mon, Apr 8, 2013 at 7:15 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> I would be ok with making the parser and format ctors public. What
> else? I agree that we should not force force folks into an API pattern
> but here it's not a big API at least.
>
> Gary
>
> On Apr 8, 2013, at 17:02, Emmanuel Bourg <ebourg@apache.org> wrote:
>
> > Le 08/04/2013 22:39, Gary Gregory a écrit :
> >
> >> But that's the price for immutability for some of these objects.
> >
> > Not sure, we already achieved immutability last year without paying this
> > price:
> >
> >
> http://svn.apache.org/repos/asf/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?p=1305548
> >
> > This design was sacrified for the sake of implementing a "by the book"
> > builder pattern that brings no real benefit in term of usability. It's
> > just a useless layer of complexity.
> >
> >
> > Emmanuel Bourg
> >
> >
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message