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, 26 Mar 2013 15:58:35 GMT
On Tue, Mar 26, 2013 at 10:05 AM, Gary Gregory <garydgregory@gmail.com>wrote:

> Hi All:
>
> This is a discussion to see if we should remove the requirement to use the
> builder pattern.
>
> Right now, the CSVParser Javadoc has this simple example:
>
> Reader in = new StringReader("a\tb\nc\td");
> CSVFormat format = new CSVFormat('\t', '"', '#');
> List<CSVRecord> records = new CSVParser(in, format).getRecords();
>
> This does not compile because we force the builder API on users but it
> shows the previous intent of the API before the builder was made a
> requirement.
>
> The CSVFormat ctor is not public and takes 9 parameters.
>
> So today, you have to write:
>
> Iterable<CSVRecord> parse =
> CSVFormat.newBuilder().withCommentStart('#').withDelimiter('\t').withQuoteChar('"').build().parse(in);
>

Is it worth providing this shortcut:

Iterable<CSVRecord> parse = CSVFormat.newBuilder().
withCommentStart('#').withDelimiter('\t').withQuoteChar('"').parse(in);

the builder would implement parse()

Gary

for (CSVRecord csvRecord : parse) {
>     // ...
> }
>
> If you use a predefined format, like Excel, then it's simpler:
>
> final Iterable<CSVRecord> parse2 = CSVFormat.EXCEL.parse(in);
>
> I see the issue flowing like this:
>
> - Let's make sure we provide the best set of CSVFormat preconfigured
> instances. Do we need different Excel formats for different Excel versions
> for example? My claim here is that if you use a preconfigured format, like
> CSVFormat.EXCEL, then the API is OK. Today we have:
>
>    - EXCEL
>    - MYSQL
>    - RFC4180
>    - RFC4180_EMPTY_LINES
>
> - If you cannot use a preconfigured format, then this is when we need to
> talk...
>
> One way to make the builder API optional is to make the CSVFormat ctor
> public. It has 9 param ctor so it's not very user friendly and does not do
> validation ATM.
>
> As soon as we do this, we run into the issue of adding ctors for 'common'
> or 'simpler' uses, which means adding a lot of ctors. At this point, we
> then have two APIs: the raw ctor (the one or a set) and the fluent builder
> API.
>
> So I have two questions:
>
> Should the CSVFormat be made public? Would that make Emmanuel happy? I am
> guessing not due to the 9 params.
>
> If the ctor is made public, should we add a bunch of ctors for simpler or
> all cases?
>
> Gary
>
> --
> 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
>



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