On 26 March 2013 16:53, Benedikt Ritter <brit...@apache.org> wrote:
> 2013/3/26 Gary Gregory <garydgreg...@gmail.com>
>
>> On Tue, Mar 26, 2013 at 12:35 PM, sebb <seb...@gmail.com> wrote:
>>
>> > On 26 March 2013 16:18, Benedikt Ritter <brit...@apache.org> wrote:
>> > > 2013/3/26 Gary Gregory <garydgreg...@gmail.com>
>> > >
>> > >> On Tue, Mar 26, 2013 at 12:03 PM, Emmanuel Bourg <ebo...@apache.org>
>> > >> wrote:
>> > >>
>> > >> > Le 26/03/2013 16:58, Gary Gregory a écrit :
>> > >> >
>> > >> > > Is it worth providing this shortcut:
>> > >> > >
>> > >> > > Iterable<CSVRecord> parse = CSVFormat.newBuilder().
>> > >> > >
>> > withCommentStart('#').withDelimiter('\t').withQuoteChar('"').parse(in);
>> > >> > >
>> > >> > > the builder would implement parse()
>> > >> >
>> > >> > I still think the builder is useless. My initial implementation
>> looked
>> > >> > like this:
>> > >> >
>> > >> > Iterable<CSVRecord> parse =
>> > >> >
>> > >> >
>> > >>
>> >
>> CSVFormat.DEFAULT.withCommentStart('#').withDelimiter('\t').withQuoteChar('"').parse(in);
>> > >> >
>> > >> > So yes, in this spirit the builder should implement parse(). But I
>> > would
>> > >> > prefer no builder at all.
>> > >> >
>> > >>
>> > >> By adding parse to the builder, we can make the builder less visible.
>> I
>> > >> think I'll add that.
>> > >>
>> > >
>> > > This was my attention when I initially created the patch for the
>> builder.
>> > > the newBuilder() method was called newFormat() back then. We changed it
>> > to
>> > > not confuse users with what objects they are dealing with. With
>> > > newBuilder() changed back to newFormat() again it would become:
>> > >
>> > > Iterable<CSVRecord> parse =
>> > >
>> >
>> CSVFormat.newFormat().withCommentStart('#').withDelimiter('\t').withQuoteChar("'").parse(in);
>> >
>> > So effectively parse would do the build and then use it for the parse?
>> >
>>
>> Yes (in SVN now) but I prefer:
>>
>>
>> CSVFormat.DEFAULT.withCommentStart('#').withDelimiter('\t').withQuoteChar("'").parse(in);
>>
>> which does not create the need for calling newBuilder() and makes it
>> obvious what it is I am building.
>>
>
> So are we back to the inital design again or do you want to change DEFAULT
> to hold a CSVBuilder?
>
>
>>
>> Gary
>>
>>
>> > Is there a use-case for re-using the format without having to re-create
>> it?
>> > If so, how would that look?
>>
>
> I'm not sure I understand your question. When parsing several files with
> the same format one would reuse a CSVFormat instance and just create new
> InputStreams for the files to parse.What I was getting at is what does the code look like to create the instance? Does this still use build() ? > >> > >> > > Benedikt >> > > >> > > >> > >> >> > >> Gary >> > >> >> > >> > >> > >> > Emmanuel Bourg >> > >> > >> > >> > >> > >> > >> > >> >> > >> >> > >> -- >> > >> E-Mail: garydgreg...@gmail.com | ggreg...@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 >> > >> >> > > >> > > >> > > >> > > -- >> > > http://people.apache.org/~britter/ >> > > http://www.systemoutprintln.de/ >> > > http://twitter.com/BenediktRitter >> > > http://github.com/britter >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@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 >> > > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
