You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2013/05/20 22:04:59 UTC
Creating CSVFormats (again :)
Hi guys,
a while back we had this discussion [1] about the current state of the
CSVFormat API. We were still not completely happy with it and Oliver came
up with a new suggestion [2].
This weekend I finally had some time to hack something together. I've
created a mirror of CSV rev. 1484347 at github [3].
This proposal uses CSVFormatModifier objects to change a CSVFormat. The API
relies on static imports of factory methods for CSVFormatModifiers and
looks like the following:
CSVFormat modifed = CSVFormat.DEFAULT.with(
delimiter(';'),
noEscape(),
commentStart('#'));
So far I've implemented methods for changing delimiter, commentStart,
escape and quote policy (have a look at CSVFormatModifierTest). The
approach has the advantage of being short like the initial implementation,
while making sure that CSVFormat is immutable and validated at construction
time. The draw back however is, that it is a bit of a pain to get all the
static imports in place (at least this is my feeling with Eclipse, any
suggestions on how to work efficiently with static imports in eclipse are
appreciated :)
Now I'd like to ask you for feedback. Do you like this approach? Any
suggestions?
One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
together with CSVFormatModifier.
Regards,
Benedikt
[1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
[2] http://markmail.org/message/vjjdbckwr4dlqp2b
[3] https://github.com/britter/apache-commons-csv-mirror
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: Creating CSVFormats (again :)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 23/05/2013 09:35, Romain Manni-Bucau a écrit :
> well i like the "propose all APIs users expect".
>
> One i didn't see (hope i didnt miss it) is a annotaton one:
I would like to see annotations in [csv] as well. My intent was to build
this on the top of a basic API in a subsequent release, but we haven't
been able to agree on this basic API yet :)
I like the idea but I fear this is going to delay further the release.
Emmanuel Bourg
Re: Creating CSVFormats (again :)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well i like the "propose all APIs users expect".
One i didn't see (hope i didnt miss it) is a annotaton one:
@CsfFormat(delimiter= ",", ...)
public class MyFormat {
@CsvColumn(value = "name") // value = fieldName by default
private String name;
@DateFormat("...")
@CsvColumn(value = "date")
private Date date;
...
}
Basically it would create:
1) fluent API
2) constructors
3) annotations
Technically all is simple but some consistency between them should be
ensured (maybe they could be generated from a list of available configs +
defaults)
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/5/23 Benedikt Ritter <br...@apache.org>
> 2013/5/21 Gary Gregory <ga...@gmail.com>
>
> > On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > 2013/5/21 Emmanuel Bourg <eb...@apache.org>
> > >
> > > > Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> > > >
> > > > > Well that still doesn't tell us, what your definition of a "real"
> > > builder
> > > > > is :-) The latest trunk contains a builder implementation with a
> > fluent
> > > > > API. It has been criticized for being to verbose when creating new
> > > > formats
> > > > > from existing ones. This is why we came up with this new proposal,
> > that
> > > > is
> > > > > less verbose but requires static imports.
> > > >
> > > > What about simply going back to the previous design (fluent API
> without
> > > > builder) ? The only drawback was the need to validate the format
> > > > explicitly. That is the best compromise IMHO.
> > > >
> > >
> > > Hi Emmanuel,
> > >
> > > I think we have discussed this a lot (maybe to much). You certainly
> know
> > my
> > > arguments against the old solution and I still think they are valid.
> > Also,
> > > I understand your arguments and think they are equally valid.
> > > I believe we have tried a lot to finally reach consensus about this
> > issue.
> > > We have tried several solutions and to me it seems, that consensus can
> > > simply not be reached (an argument that can't be settled in 5 minutes
> > can't
> > > be settled with arguments at all).
> > >
> > > Having this said, I'm willing to give my +0 for going back for the old
> > impl
> > > if the others (by this I specially me Gary and sebb) also agree.
> > > I believe that this issue has blocked us for such a long time from
> > pushing
> > > csv forward, that it is time to overcome personal preferences and just
> > > chose one solution or the other.
> > >
> > > So if you can at least convince Gary and sebb, let's do it and then go
> > on.
> > > I want to see csv see the light of day :-)
> > >
> >
> > Nice message Benedikt.
> >
>
> Thanks :)
>
>
> >
> > At the end of the day, here is what I am looking for: Don't force me to
> use
> > a style of API to use the product. If I want to use fat constructors that
> > may be hard to read, let me. If I want to use a fluent API, provide it
> and
> > let people who like that style use it. At a lower level, do make things
> > immutable where they make sense. If the fluent API and/or the
> immutability
> > of some objects has the side effect or creating a lot of garbage, then
> that
> > is the cost of using that feature, which is why I do not want to force
> > people to use it. Let there be light ;)
> >
>
> So this is your +1 for the old API + public ctor?
>
> I'm excited to hear sebb's opinion :)
>
> Benedikt
>
>
> >
> > Gary
> >
> >
> > > Benedikt
> > >
> > >
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > 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
>
Re: Creating CSVFormats (again :)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 05/06/2013 15:22, Benedikt Ritter a écrit :
> Sorry, for the late follow up...
> What we are talking about is probably something like r1399051 [1] but with
> a public ctor.
>
> WDYT?
+1 !
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Creating CSVFormats (again :)
Posted by Benedikt Ritter <be...@gmail.com>.
Am 06.06.2013 um 18:21 schrieb Gary Gregory <ga...@gmail.com>:
> On Wed, Jun 5, 2013 at 9:22 AM, Benedikt Ritter <br...@apache.org> wrote:
>
>> 2013/5/23 Gary Gregory <ga...@gmail.com>
>>
>>> On Thu, May 23, 2013 at 3:31 AM, Benedikt Ritter <br...@apache.org>
>>> wrote:
>>>
>>>> 2013/5/21 Gary Gregory <ga...@gmail.com>
>>>>
>>>>> On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <britter@apache.org
>>>
>>>>> wrote:
>>>>>
>>>>>> 2013/5/21 Emmanuel Bourg <eb...@apache.org>
>>>>>>
>>>>>>> Le 21/05/2013 17:47, Benedikt Ritter a écrit :
>>>>>>>
>>>>>>>> Well that still doesn't tell us, what your definition of a
>> "real"
>>>>>> builder
>>>>>>>> is :-) The latest trunk contains a builder implementation with
>> a
>>>>> fluent
>>>>>>>> API. It has been criticized for being to verbose when creating
>>> new
>>>>>>> formats
>>>>>>>> from existing ones. This is why we came up with this new
>>> proposal,
>>>>> that
>>>>>>> is
>>>>>>>> less verbose but requires static imports.
>>>>>>>
>>>>>>> What about simply going back to the previous design (fluent API
>>>> without
>>>>>>> builder) ? The only drawback was the need to validate the format
>>>>>>> explicitly. That is the best compromise IMHO.
>>>>>>>
>>>>>>
>>>>>> Hi Emmanuel,
>>>>>>
>>>>>> I think we have discussed this a lot (maybe to much). You certainly
>>>> know
>>>>> my
>>>>>> arguments against the old solution and I still think they are
>> valid.
>>>>> Also,
>>>>>> I understand your arguments and think they are equally valid.
>>>>>> I believe we have tried a lot to finally reach consensus about this
>>>>> issue.
>>>>>> We have tried several solutions and to me it seems, that consensus
>>> can
>>>>>> simply not be reached (an argument that can't be settled in 5
>> minutes
>>>>> can't
>>>>>> be settled with arguments at all).
>>>>>>
>>>>>> Having this said, I'm willing to give my +0 for going back for the
>>> old
>>>>> impl
>>>>>> if the others (by this I specially me Gary and sebb) also agree.
>>>>>> I believe that this issue has blocked us for such a long time from
>>>>> pushing
>>>>>> csv forward, that it is time to overcome personal preferences and
>>> just
>>>>>> chose one solution or the other.
>>>>>>
>>>>>> So if you can at least convince Gary and sebb, let's do it and then
>>> go
>>>>> on.
>>>>>> I want to see csv see the light of day :-)
>>>>>>
>>>>>
>>>>> Nice message Benedikt.
>>>>>
>>>>
>>>> Thanks :)
>>>>
>>>>
>>>>>
>>>>> At the end of the day, here is what I am looking for: Don't force me
>> to
>>>> use
>>>>> a style of API to use the product. If I want to use fat constructors
>>> that
>>>>> may be hard to read, let me. If I want to use a fluent API, provide
>> it
>>>> and
>>>>> let people who like that style use it. At a lower level, do make
>> things
>>>>> immutable where they make sense. If the fluent API and/or the
>>>> immutability
>>>>> of some objects has the side effect or creating a lot of garbage,
>> then
>>>> that
>>>>> is the cost of using that feature, which is why I do not want to
>> force
>>>>> people to use it. Let there be light ;)
>>>>>
>>>>
>>>> So this is your +1 for the old API + public ctor?
>>>>
>>>
>>> I'm not sure which is which anymore and I do not want to take the time
>>> today to dive back in this one. But it does feel we are getting close...
>> to
>>> something ;)
>>>
>>
>>
>> Sorry, for the late follow up...
>> What we are talking about is probably something like r1399051 [1] but with
>> a public ctor.
>>
>> WDYT?
>>
>
> That should be OK. Turning the default ctor into a public one should
> satisfy both audiences: the fluent-obsessed and the I-know-what-I'm-doing.
I have created CSV-99 [1] to keep track of this change.
Benedikt
[1] https://issues.apache.org/jira/browse/CSV-99
>
> Gary
>
>
>>
>> Benedikt
>>
>> [1]
>>
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?revision=1399051&view=markup
>>
>>
>>>
>>> Gary
>>>
>>>>
>>>> I'm excited to hear sebb's opinion :)
>>>>
>>>> Benedikt
>>>>
>>>>
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>> Benedikt
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Emmanuel Bourg
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://people.apache.org/~britter/
>>>>>> http://www.systemoutprintln.de/
>>>>>> http://twitter.com/BenediktRitter
>>>>>> http://github.com/britter
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<
>>>>> http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<
>>> http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> 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
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Creating CSVFormats (again :)
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jun 5, 2013 at 9:22 AM, Benedikt Ritter <br...@apache.org> wrote:
> 2013/5/23 Gary Gregory <ga...@gmail.com>
>
> > On Thu, May 23, 2013 at 3:31 AM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > 2013/5/21 Gary Gregory <ga...@gmail.com>
> > >
> > > > On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <britter@apache.org
> >
> > > > wrote:
> > > >
> > > > > 2013/5/21 Emmanuel Bourg <eb...@apache.org>
> > > > >
> > > > > > Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> > > > > >
> > > > > > > Well that still doesn't tell us, what your definition of a
> "real"
> > > > > builder
> > > > > > > is :-) The latest trunk contains a builder implementation with
> a
> > > > fluent
> > > > > > > API. It has been criticized for being to verbose when creating
> > new
> > > > > > formats
> > > > > > > from existing ones. This is why we came up with this new
> > proposal,
> > > > that
> > > > > > is
> > > > > > > less verbose but requires static imports.
> > > > > >
> > > > > > What about simply going back to the previous design (fluent API
> > > without
> > > > > > builder) ? The only drawback was the need to validate the format
> > > > > > explicitly. That is the best compromise IMHO.
> > > > > >
> > > > >
> > > > > Hi Emmanuel,
> > > > >
> > > > > I think we have discussed this a lot (maybe to much). You certainly
> > > know
> > > > my
> > > > > arguments against the old solution and I still think they are
> valid.
> > > > Also,
> > > > > I understand your arguments and think they are equally valid.
> > > > > I believe we have tried a lot to finally reach consensus about this
> > > > issue.
> > > > > We have tried several solutions and to me it seems, that consensus
> > can
> > > > > simply not be reached (an argument that can't be settled in 5
> minutes
> > > > can't
> > > > > be settled with arguments at all).
> > > > >
> > > > > Having this said, I'm willing to give my +0 for going back for the
> > old
> > > > impl
> > > > > if the others (by this I specially me Gary and sebb) also agree.
> > > > > I believe that this issue has blocked us for such a long time from
> > > > pushing
> > > > > csv forward, that it is time to overcome personal preferences and
> > just
> > > > > chose one solution or the other.
> > > > >
> > > > > So if you can at least convince Gary and sebb, let's do it and then
> > go
> > > > on.
> > > > > I want to see csv see the light of day :-)
> > > > >
> > > >
> > > > Nice message Benedikt.
> > > >
> > >
> > > Thanks :)
> > >
> > >
> > > >
> > > > At the end of the day, here is what I am looking for: Don't force me
> to
> > > use
> > > > a style of API to use the product. If I want to use fat constructors
> > that
> > > > may be hard to read, let me. If I want to use a fluent API, provide
> it
> > > and
> > > > let people who like that style use it. At a lower level, do make
> things
> > > > immutable where they make sense. If the fluent API and/or the
> > > immutability
> > > > of some objects has the side effect or creating a lot of garbage,
> then
> > > that
> > > > is the cost of using that feature, which is why I do not want to
> force
> > > > people to use it. Let there be light ;)
> > > >
> > >
> > > So this is your +1 for the old API + public ctor?
> > >
> >
> > I'm not sure which is which anymore and I do not want to take the time
> > today to dive back in this one. But it does feel we are getting close...
> to
> > something ;)
> >
>
>
> Sorry, for the late follow up...
> What we are talking about is probably something like r1399051 [1] but with
> a public ctor.
>
> WDYT?
>
That should be OK. Turning the default ctor into a public one should
satisfy both audiences: the fluent-obsessed and the I-know-what-I'm-doing.
Gary
>
> Benedikt
>
> [1]
>
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?revision=1399051&view=markup
>
>
> >
> > Gary
> >
> > >
> > > I'm excited to hear sebb's opinion :)
> > >
> > > Benedikt
> > >
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > > Benedikt
> > > > >
> > > > >
> > > > > >
> > > > > > Emmanuel Bourg
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://people.apache.org/~britter/
> > > > > http://www.systemoutprintln.de/
> > > > > http://twitter.com/BenediktRitter
> > > > > http://github.com/britter
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > Java Persistence with Hibernate, Second Edition<
> > > > http://www.manning.com/bauer3/>
> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > > Spring Batch in Action <http://www.manning.com/templier/>
> > > > 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
> > >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > 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
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Creating CSVFormats (again :)
Posted by Benedikt Ritter <br...@apache.org>.
2013/5/23 Gary Gregory <ga...@gmail.com>
> On Thu, May 23, 2013 at 3:31 AM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > 2013/5/21 Gary Gregory <ga...@gmail.com>
> >
> > > On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <br...@apache.org>
> > > wrote:
> > >
> > > > 2013/5/21 Emmanuel Bourg <eb...@apache.org>
> > > >
> > > > > Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> > > > >
> > > > > > Well that still doesn't tell us, what your definition of a "real"
> > > > builder
> > > > > > is :-) The latest trunk contains a builder implementation with a
> > > fluent
> > > > > > API. It has been criticized for being to verbose when creating
> new
> > > > > formats
> > > > > > from existing ones. This is why we came up with this new
> proposal,
> > > that
> > > > > is
> > > > > > less verbose but requires static imports.
> > > > >
> > > > > What about simply going back to the previous design (fluent API
> > without
> > > > > builder) ? The only drawback was the need to validate the format
> > > > > explicitly. That is the best compromise IMHO.
> > > > >
> > > >
> > > > Hi Emmanuel,
> > > >
> > > > I think we have discussed this a lot (maybe to much). You certainly
> > know
> > > my
> > > > arguments against the old solution and I still think they are valid.
> > > Also,
> > > > I understand your arguments and think they are equally valid.
> > > > I believe we have tried a lot to finally reach consensus about this
> > > issue.
> > > > We have tried several solutions and to me it seems, that consensus
> can
> > > > simply not be reached (an argument that can't be settled in 5 minutes
> > > can't
> > > > be settled with arguments at all).
> > > >
> > > > Having this said, I'm willing to give my +0 for going back for the
> old
> > > impl
> > > > if the others (by this I specially me Gary and sebb) also agree.
> > > > I believe that this issue has blocked us for such a long time from
> > > pushing
> > > > csv forward, that it is time to overcome personal preferences and
> just
> > > > chose one solution or the other.
> > > >
> > > > So if you can at least convince Gary and sebb, let's do it and then
> go
> > > on.
> > > > I want to see csv see the light of day :-)
> > > >
> > >
> > > Nice message Benedikt.
> > >
> >
> > Thanks :)
> >
> >
> > >
> > > At the end of the day, here is what I am looking for: Don't force me to
> > use
> > > a style of API to use the product. If I want to use fat constructors
> that
> > > may be hard to read, let me. If I want to use a fluent API, provide it
> > and
> > > let people who like that style use it. At a lower level, do make things
> > > immutable where they make sense. If the fluent API and/or the
> > immutability
> > > of some objects has the side effect or creating a lot of garbage, then
> > that
> > > is the cost of using that feature, which is why I do not want to force
> > > people to use it. Let there be light ;)
> > >
> >
> > So this is your +1 for the old API + public ctor?
> >
>
> I'm not sure which is which anymore and I do not want to take the time
> today to dive back in this one. But it does feel we are getting close... to
> something ;)
>
Sorry, for the late follow up...
What we are talking about is probably something like r1399051 [1] but with
a public ctor.
WDYT?
Benedikt
[1]
http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?revision=1399051&view=markup
>
> Gary
>
> >
> > I'm excited to hear sebb's opinion :)
> >
> > Benedikt
> >
> >
> > >
> > > Gary
> > >
> > >
> > > > Benedikt
> > > >
> > > >
> > > > >
> > > > > Emmanuel Bourg
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://people.apache.org/~britter/
> > > > http://www.systemoutprintln.de/
> > > > http://twitter.com/BenediktRitter
> > > > http://github.com/britter
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > > Spring Batch in Action <http://www.manning.com/templier/>
> > > 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
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> 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
Re: Creating CSVFormats (again :)
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, May 23, 2013 at 3:31 AM, Benedikt Ritter <br...@apache.org> wrote:
> 2013/5/21 Gary Gregory <ga...@gmail.com>
>
> > On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <br...@apache.org>
> > wrote:
> >
> > > 2013/5/21 Emmanuel Bourg <eb...@apache.org>
> > >
> > > > Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> > > >
> > > > > Well that still doesn't tell us, what your definition of a "real"
> > > builder
> > > > > is :-) The latest trunk contains a builder implementation with a
> > fluent
> > > > > API. It has been criticized for being to verbose when creating new
> > > > formats
> > > > > from existing ones. This is why we came up with this new proposal,
> > that
> > > > is
> > > > > less verbose but requires static imports.
> > > >
> > > > What about simply going back to the previous design (fluent API
> without
> > > > builder) ? The only drawback was the need to validate the format
> > > > explicitly. That is the best compromise IMHO.
> > > >
> > >
> > > Hi Emmanuel,
> > >
> > > I think we have discussed this a lot (maybe to much). You certainly
> know
> > my
> > > arguments against the old solution and I still think they are valid.
> > Also,
> > > I understand your arguments and think they are equally valid.
> > > I believe we have tried a lot to finally reach consensus about this
> > issue.
> > > We have tried several solutions and to me it seems, that consensus can
> > > simply not be reached (an argument that can't be settled in 5 minutes
> > can't
> > > be settled with arguments at all).
> > >
> > > Having this said, I'm willing to give my +0 for going back for the old
> > impl
> > > if the others (by this I specially me Gary and sebb) also agree.
> > > I believe that this issue has blocked us for such a long time from
> > pushing
> > > csv forward, that it is time to overcome personal preferences and just
> > > chose one solution or the other.
> > >
> > > So if you can at least convince Gary and sebb, let's do it and then go
> > on.
> > > I want to see csv see the light of day :-)
> > >
> >
> > Nice message Benedikt.
> >
>
> Thanks :)
>
>
> >
> > At the end of the day, here is what I am looking for: Don't force me to
> use
> > a style of API to use the product. If I want to use fat constructors that
> > may be hard to read, let me. If I want to use a fluent API, provide it
> and
> > let people who like that style use it. At a lower level, do make things
> > immutable where they make sense. If the fluent API and/or the
> immutability
> > of some objects has the side effect or creating a lot of garbage, then
> that
> > is the cost of using that feature, which is why I do not want to force
> > people to use it. Let there be light ;)
> >
>
> So this is your +1 for the old API + public ctor?
>
I'm not sure which is which anymore and I do not want to take the time
today to dive back in this one. But it does feel we are getting close... to
something ;)
Gary
>
> I'm excited to hear sebb's opinion :)
>
> Benedikt
>
>
> >
> > Gary
> >
> >
> > > Benedikt
> > >
> > >
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> > >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > 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
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Creating CSVFormats (again :)
Posted by Benedikt Ritter <br...@apache.org>.
2013/5/21 Gary Gregory <ga...@gmail.com>
> On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > 2013/5/21 Emmanuel Bourg <eb...@apache.org>
> >
> > > Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> > >
> > > > Well that still doesn't tell us, what your definition of a "real"
> > builder
> > > > is :-) The latest trunk contains a builder implementation with a
> fluent
> > > > API. It has been criticized for being to verbose when creating new
> > > formats
> > > > from existing ones. This is why we came up with this new proposal,
> that
> > > is
> > > > less verbose but requires static imports.
> > >
> > > What about simply going back to the previous design (fluent API without
> > > builder) ? The only drawback was the need to validate the format
> > > explicitly. That is the best compromise IMHO.
> > >
> >
> > Hi Emmanuel,
> >
> > I think we have discussed this a lot (maybe to much). You certainly know
> my
> > arguments against the old solution and I still think they are valid.
> Also,
> > I understand your arguments and think they are equally valid.
> > I believe we have tried a lot to finally reach consensus about this
> issue.
> > We have tried several solutions and to me it seems, that consensus can
> > simply not be reached (an argument that can't be settled in 5 minutes
> can't
> > be settled with arguments at all).
> >
> > Having this said, I'm willing to give my +0 for going back for the old
> impl
> > if the others (by this I specially me Gary and sebb) also agree.
> > I believe that this issue has blocked us for such a long time from
> pushing
> > csv forward, that it is time to overcome personal preferences and just
> > chose one solution or the other.
> >
> > So if you can at least convince Gary and sebb, let's do it and then go
> on.
> > I want to see csv see the light of day :-)
> >
>
> Nice message Benedikt.
>
Thanks :)
>
> At the end of the day, here is what I am looking for: Don't force me to use
> a style of API to use the product. If I want to use fat constructors that
> may be hard to read, let me. If I want to use a fluent API, provide it and
> let people who like that style use it. At a lower level, do make things
> immutable where they make sense. If the fluent API and/or the immutability
> of some objects has the side effect or creating a lot of garbage, then that
> is the cost of using that feature, which is why I do not want to force
> people to use it. Let there be light ;)
>
So this is your +1 for the old API + public ctor?
I'm excited to hear sebb's opinion :)
Benedikt
>
> Gary
>
>
> > Benedikt
> >
> >
> > >
> > > Emmanuel Bourg
> > >
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> 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
Re: Creating CSVFormats (again :)
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <br...@apache.org> wrote:
> 2013/5/21 Emmanuel Bourg <eb...@apache.org>
>
> > Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> >
> > > Well that still doesn't tell us, what your definition of a "real"
> builder
> > > is :-) The latest trunk contains a builder implementation with a fluent
> > > API. It has been criticized for being to verbose when creating new
> > formats
> > > from existing ones. This is why we came up with this new proposal, that
> > is
> > > less verbose but requires static imports.
> >
> > What about simply going back to the previous design (fluent API without
> > builder) ? The only drawback was the need to validate the format
> > explicitly. That is the best compromise IMHO.
> >
>
> Hi Emmanuel,
>
> I think we have discussed this a lot (maybe to much). You certainly know my
> arguments against the old solution and I still think they are valid. Also,
> I understand your arguments and think they are equally valid.
> I believe we have tried a lot to finally reach consensus about this issue.
> We have tried several solutions and to me it seems, that consensus can
> simply not be reached (an argument that can't be settled in 5 minutes can't
> be settled with arguments at all).
>
> Having this said, I'm willing to give my +0 for going back for the old impl
> if the others (by this I specially me Gary and sebb) also agree.
> I believe that this issue has blocked us for such a long time from pushing
> csv forward, that it is time to overcome personal preferences and just
> chose one solution or the other.
>
> So if you can at least convince Gary and sebb, let's do it and then go on.
> I want to see csv see the light of day :-)
>
Nice message Benedikt.
At the end of the day, here is what I am looking for: Don't force me to use
a style of API to use the product. If I want to use fat constructors that
may be hard to read, let me. If I want to use a fluent API, provide it and
let people who like that style use it. At a lower level, do make things
immutable where they make sense. If the fluent API and/or the immutability
of some objects has the side effect or creating a lot of garbage, then that
is the cost of using that feature, which is why I do not want to force
people to use it. Let there be light ;)
Gary
> Benedikt
>
>
> >
> > Emmanuel Bourg
> >
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Creating CSVFormats (again :)
Posted by Benedikt Ritter <br...@apache.org>.
2013/5/21 Emmanuel Bourg <eb...@apache.org>
> Le 21/05/2013 17:47, Benedikt Ritter a écrit :
>
> > Well that still doesn't tell us, what your definition of a "real" builder
> > is :-) The latest trunk contains a builder implementation with a fluent
> > API. It has been criticized for being to verbose when creating new
> formats
> > from existing ones. This is why we came up with this new proposal, that
> is
> > less verbose but requires static imports.
>
> What about simply going back to the previous design (fluent API without
> builder) ? The only drawback was the need to validate the format
> explicitly. That is the best compromise IMHO.
>
Hi Emmanuel,
I think we have discussed this a lot (maybe to much). You certainly know my
arguments against the old solution and I still think they are valid. Also,
I understand your arguments and think they are equally valid.
I believe we have tried a lot to finally reach consensus about this issue.
We have tried several solutions and to me it seems, that consensus can
simply not be reached (an argument that can't be settled in 5 minutes can't
be settled with arguments at all).
Having this said, I'm willing to give my +0 for going back for the old impl
if the others (by this I specially me Gary and sebb) also agree.
I believe that this issue has blocked us for such a long time from pushing
csv forward, that it is time to overcome personal preferences and just
chose one solution or the other.
So if you can at least convince Gary and sebb, let's do it and then go on.
I want to see csv see the light of day :-)
Benedikt
>
> Emmanuel Bourg
>
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: Creating CSVFormats (again :)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
real builder meant fluent api for me. Current API is fine IMO, it is
verbose but if you think so you quickly write your own format and that's
fine.
basically with a fluent builder you are 1/1 with the config so you can't be
less verbose excepted using multi-param constructor/factories which is more
complicated to handle from the lib side IMO.
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/5/21 Emmanuel Bourg <eb...@apache.org>
> Le 21/05/2013 17:47, Benedikt Ritter a écrit :
>
> > Well that still doesn't tell us, what your definition of a "real" builder
> > is :-) The latest trunk contains a builder implementation with a fluent
> > API. It has been criticized for being to verbose when creating new
> formats
> > from existing ones. This is why we came up with this new proposal, that
> is
> > less verbose but requires static imports.
>
> What about simply going back to the previous design (fluent API without
> builder) ? The only drawback was the need to validate the format
> explicitly. That is the best compromise IMHO.
>
> Emmanuel Bourg
>
>
>
Re: Creating CSVFormats (again :)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 21/05/2013 17:47, Benedikt Ritter a écrit :
> Well that still doesn't tell us, what your definition of a "real" builder
> is :-) The latest trunk contains a builder implementation with a fluent
> API. It has been criticized for being to verbose when creating new formats
> from existing ones. This is why we came up with this new proposal, that is
> less verbose but requires static imports.
What about simply going back to the previous design (fluent API without
builder) ? The only drawback was the need to validate the format
explicitly. That is the best compromise IMHO.
Emmanuel Bourg
Re: Creating CSVFormats (again :)
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, May 21, 2013 at 11:47 AM, Benedikt Ritter <br...@apache.org>wrote:
> 2013/5/21 Romain Manni-Bucau <rm...@gmail.com>
>
> > The CSVConfig solution is better IMO.
> >
> > The issue with static imports is only an issue if the api is not fluent
> > (delimiter, comment ...). If after one or two static imports (without *
> ;)
> > you get what i called a real builder (a fluent api) it is far easier to
> > enter the api.
> >
>
> Well that still doesn't tell us, what your definition of a "real" builder
> is :-) The latest trunk contains a builder implementation with a fluent
> API. It has been criticized for being to verbose when creating new formats
> from existing ones. This is why we came up with this new proposal, that is
> less verbose but requires static imports.
>
The only thing I use static imports are math-type constants. I find them
misleading and non-OO for methods because I have NO IDEA what object I am
sending a message to.
Gary
>
> Benedikt
>
>
> >
> > JUnit is different cause you dont configure/build sthg, you just call
> sthg
> > line by line.
> > Le 21 mai 2013 00:42, "sebb" <se...@gmail.com> a écrit :
> >
> > > On 20 May 2013 21:07, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> > > > Hi
> > > >
> > > > A real inline builder (withDelimiter(...)...) is better to get
> > completion
> > > > and linear reading of the code IMO
> > >
> > > What do you mean exactly by a real builder?
> > > Please show the exact syntax.
> > >
> > > > Static imports are not fine for everbody from my experience
> > >
> > > Nothing is going to be fine for everybody.
> > > But static imports seem to work quite well for JUnit4.
> > >
> > > > Le 20 mai 2013 22:05, "Benedikt Ritter" <br...@apache.org> a
> écrit :
> > > >
> > > >> Hi guys,
> > > >>
> > > >> a while back we had this discussion [1] about the current state of
> the
> > > >> CSVFormat API. We were still not completely happy with it and Oliver
> > > came
> > > >> up with a new suggestion [2].
> > > >> This weekend I finally had some time to hack something together.
> I've
> > > >> created a mirror of CSV rev. 1484347 at github [3].
> > > >>
> > > >> This proposal uses CSVFormatModifier objects to change a CSVFormat.
> > The
> > > API
> > > >> relies on static imports of factory methods for CSVFormatModifiers
> and
> > > >> looks like the following:
> > > >>
> > > >> CSVFormat modifed = CSVFormat.DEFAULT.with(
> > >
> > > I don't like the DEFAULT; seems to me it could be dropped.
> > >
> > > >> delimiter(';'),
> > > >> noEscape(),
> > > >> commentStart('#'));
> > >
> > > Also, I think one could chain the method parameters like so:
> > >
> > > CSVFormat modifed =
> > > CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote('"'));
> > >
> > > I think this would eliminate the need for static imports.
> > >
> > > >> So far I've implemented methods for changing delimiter,
> commentStart,
> > > >> escape and quote policy (have a look at CSVFormatModifierTest). The
> > > >> approach has the advantage of being short like the initial
> > > implementation,
> > > >> while making sure that CSVFormat is immutable and validated at
> > > construction
> > > >> time. The draw back however is, that it is a bit of a pain to get
> all
> > > the
> > > >> static imports in place (at least this is my feeling with Eclipse,
> any
> > > >> suggestions on how to work efficiently with static imports in
> eclipse
> > > are
> > > >> appreciated :)
> > > >>
> > > >> Now I'd like to ask you for feedback. Do you like this approach? Any
> > > >> suggestions?
> > > >> One thing I'm not sure about is MutableCSVFormat. Maybe this can be
> > > merged
> > > >> together with CSVFormatModifier.
> > > >>
> > > >> Regards,
> > > >> Benedikt
> > > >>
> > > >>
> > > >> [1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
> > > >> [2] http://markmail.org/message/vjjdbckwr4dlqp2b
> > > >> [3] https://github.com/britter/apache-commons-csv-mirror
> > > >>
> > > >>
> > > >> --
> > > >> http://people.apache.org/~britter/
> > > >> http://www.systemoutprintln.de/
> > > >> http://twitter.com/BenediktRitter
> > > >> http://github.com/britter
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Creating CSVFormats (again :)
Posted by Benedikt Ritter <br...@apache.org>.
2013/5/21 Romain Manni-Bucau <rm...@gmail.com>
> The CSVConfig solution is better IMO.
>
> The issue with static imports is only an issue if the api is not fluent
> (delimiter, comment ...). If after one or two static imports (without * ;)
> you get what i called a real builder (a fluent api) it is far easier to
> enter the api.
>
Well that still doesn't tell us, what your definition of a "real" builder
is :-) The latest trunk contains a builder implementation with a fluent
API. It has been criticized for being to verbose when creating new formats
from existing ones. This is why we came up with this new proposal, that is
less verbose but requires static imports.
Benedikt
>
> JUnit is different cause you dont configure/build sthg, you just call sthg
> line by line.
> Le 21 mai 2013 00:42, "sebb" <se...@gmail.com> a écrit :
>
> > On 20 May 2013 21:07, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > > Hi
> > >
> > > A real inline builder (withDelimiter(...)...) is better to get
> completion
> > > and linear reading of the code IMO
> >
> > What do you mean exactly by a real builder?
> > Please show the exact syntax.
> >
> > > Static imports are not fine for everbody from my experience
> >
> > Nothing is going to be fine for everybody.
> > But static imports seem to work quite well for JUnit4.
> >
> > > Le 20 mai 2013 22:05, "Benedikt Ritter" <br...@apache.org> a écrit :
> > >
> > >> Hi guys,
> > >>
> > >> a while back we had this discussion [1] about the current state of the
> > >> CSVFormat API. We were still not completely happy with it and Oliver
> > came
> > >> up with a new suggestion [2].
> > >> This weekend I finally had some time to hack something together. I've
> > >> created a mirror of CSV rev. 1484347 at github [3].
> > >>
> > >> This proposal uses CSVFormatModifier objects to change a CSVFormat.
> The
> > API
> > >> relies on static imports of factory methods for CSVFormatModifiers and
> > >> looks like the following:
> > >>
> > >> CSVFormat modifed = CSVFormat.DEFAULT.with(
> >
> > I don't like the DEFAULT; seems to me it could be dropped.
> >
> > >> delimiter(';'),
> > >> noEscape(),
> > >> commentStart('#'));
> >
> > Also, I think one could chain the method parameters like so:
> >
> > CSVFormat modifed =
> > CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote('"'));
> >
> > I think this would eliminate the need for static imports.
> >
> > >> So far I've implemented methods for changing delimiter, commentStart,
> > >> escape and quote policy (have a look at CSVFormatModifierTest). The
> > >> approach has the advantage of being short like the initial
> > implementation,
> > >> while making sure that CSVFormat is immutable and validated at
> > construction
> > >> time. The draw back however is, that it is a bit of a pain to get all
> > the
> > >> static imports in place (at least this is my feeling with Eclipse, any
> > >> suggestions on how to work efficiently with static imports in eclipse
> > are
> > >> appreciated :)
> > >>
> > >> Now I'd like to ask you for feedback. Do you like this approach? Any
> > >> suggestions?
> > >> One thing I'm not sure about is MutableCSVFormat. Maybe this can be
> > merged
> > >> together with CSVFormatModifier.
> > >>
> > >> Regards,
> > >> Benedikt
> > >>
> > >>
> > >> [1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
> > >> [2] http://markmail.org/message/vjjdbckwr4dlqp2b
> > >> [3] https://github.com/britter/apache-commons-csv-mirror
> > >>
> > >>
> > >> --
> > >> http://people.apache.org/~britter/
> > >> http://www.systemoutprintln.de/
> > >> http://twitter.com/BenediktRitter
> > >> http://github.com/britter
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: Creating CSVFormats (again :)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
The CSVConfig solution is better IMO.
The issue with static imports is only an issue if the api is not fluent
(delimiter, comment ...). If after one or two static imports (without * ;)
you get what i called a real builder (a fluent api) it is far easier to
enter the api.
JUnit is different cause you dont configure/build sthg, you just call sthg
line by line.
Le 21 mai 2013 00:42, "sebb" <se...@gmail.com> a écrit :
> On 20 May 2013 21:07, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > Hi
> >
> > A real inline builder (withDelimiter(...)...) is better to get completion
> > and linear reading of the code IMO
>
> What do you mean exactly by a real builder?
> Please show the exact syntax.
>
> > Static imports are not fine for everbody from my experience
>
> Nothing is going to be fine for everybody.
> But static imports seem to work quite well for JUnit4.
>
> > Le 20 mai 2013 22:05, "Benedikt Ritter" <br...@apache.org> a écrit :
> >
> >> Hi guys,
> >>
> >> a while back we had this discussion [1] about the current state of the
> >> CSVFormat API. We were still not completely happy with it and Oliver
> came
> >> up with a new suggestion [2].
> >> This weekend I finally had some time to hack something together. I've
> >> created a mirror of CSV rev. 1484347 at github [3].
> >>
> >> This proposal uses CSVFormatModifier objects to change a CSVFormat. The
> API
> >> relies on static imports of factory methods for CSVFormatModifiers and
> >> looks like the following:
> >>
> >> CSVFormat modifed = CSVFormat.DEFAULT.with(
>
> I don't like the DEFAULT; seems to me it could be dropped.
>
> >> delimiter(';'),
> >> noEscape(),
> >> commentStart('#'));
>
> Also, I think one could chain the method parameters like so:
>
> CSVFormat modifed =
> CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote('"'));
>
> I think this would eliminate the need for static imports.
>
> >> So far I've implemented methods for changing delimiter, commentStart,
> >> escape and quote policy (have a look at CSVFormatModifierTest). The
> >> approach has the advantage of being short like the initial
> implementation,
> >> while making sure that CSVFormat is immutable and validated at
> construction
> >> time. The draw back however is, that it is a bit of a pain to get all
> the
> >> static imports in place (at least this is my feeling with Eclipse, any
> >> suggestions on how to work efficiently with static imports in eclipse
> are
> >> appreciated :)
> >>
> >> Now I'd like to ask you for feedback. Do you like this approach? Any
> >> suggestions?
> >> One thing I'm not sure about is MutableCSVFormat. Maybe this can be
> merged
> >> together with CSVFormatModifier.
> >>
> >> Regards,
> >> Benedikt
> >>
> >>
> >> [1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
> >> [2] http://markmail.org/message/vjjdbckwr4dlqp2b
> >> [3] https://github.com/britter/apache-commons-csv-mirror
> >>
> >>
> >> --
> >> http://people.apache.org/~britter/
> >> http://www.systemoutprintln.de/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Creating CSVFormats (again :)
Posted by sebb <se...@gmail.com>.
On 20 May 2013 21:07, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hi
>
> A real inline builder (withDelimiter(...)...) is better to get completion
> and linear reading of the code IMO
What do you mean exactly by a real builder?
Please show the exact syntax.
> Static imports are not fine for everbody from my experience
Nothing is going to be fine for everybody.
But static imports seem to work quite well for JUnit4.
> Le 20 mai 2013 22:05, "Benedikt Ritter" <br...@apache.org> a écrit :
>
>> Hi guys,
>>
>> a while back we had this discussion [1] about the current state of the
>> CSVFormat API. We were still not completely happy with it and Oliver came
>> up with a new suggestion [2].
>> This weekend I finally had some time to hack something together. I've
>> created a mirror of CSV rev. 1484347 at github [3].
>>
>> This proposal uses CSVFormatModifier objects to change a CSVFormat. The API
>> relies on static imports of factory methods for CSVFormatModifiers and
>> looks like the following:
>>
>> CSVFormat modifed = CSVFormat.DEFAULT.with(
I don't like the DEFAULT; seems to me it could be dropped.
>> delimiter(';'),
>> noEscape(),
>> commentStart('#'));
Also, I think one could chain the method parameters like so:
CSVFormat modifed =
CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote('"'));
I think this would eliminate the need for static imports.
>> So far I've implemented methods for changing delimiter, commentStart,
>> escape and quote policy (have a look at CSVFormatModifierTest). The
>> approach has the advantage of being short like the initial implementation,
>> while making sure that CSVFormat is immutable and validated at construction
>> time. The draw back however is, that it is a bit of a pain to get all the
>> static imports in place (at least this is my feeling with Eclipse, any
>> suggestions on how to work efficiently with static imports in eclipse are
>> appreciated :)
>>
>> Now I'd like to ask you for feedback. Do you like this approach? Any
>> suggestions?
>> One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
>> together with CSVFormatModifier.
>>
>> Regards,
>> Benedikt
>>
>>
>> [1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
>> [2] http://markmail.org/message/vjjdbckwr4dlqp2b
>> [3] https://github.com/britter/apache-commons-csv-mirror
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Creating CSVFormats (again :)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 20/05/2013 22:07, Romain Manni-Bucau a écrit :
> A real inline builder (withDelimiter(...)...) is better to get completion
> and linear reading of the code IMO
+1
Emmanuel Bourg
Re: Creating CSVFormats (again :)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
A real inline builder (withDelimiter(...)...) is better to get completion
and linear reading of the code IMO
Static imports are not fine for everbody from my experience
Le 20 mai 2013 22:05, "Benedikt Ritter" <br...@apache.org> a écrit :
> Hi guys,
>
> a while back we had this discussion [1] about the current state of the
> CSVFormat API. We were still not completely happy with it and Oliver came
> up with a new suggestion [2].
> This weekend I finally had some time to hack something together. I've
> created a mirror of CSV rev. 1484347 at github [3].
>
> This proposal uses CSVFormatModifier objects to change a CSVFormat. The API
> relies on static imports of factory methods for CSVFormatModifiers and
> looks like the following:
>
> CSVFormat modifed = CSVFormat.DEFAULT.with(
> delimiter(';'),
> noEscape(),
> commentStart('#'));
>
> So far I've implemented methods for changing delimiter, commentStart,
> escape and quote policy (have a look at CSVFormatModifierTest). The
> approach has the advantage of being short like the initial implementation,
> while making sure that CSVFormat is immutable and validated at construction
> time. The draw back however is, that it is a bit of a pain to get all the
> static imports in place (at least this is my feeling with Eclipse, any
> suggestions on how to work efficiently with static imports in eclipse are
> appreciated :)
>
> Now I'd like to ask you for feedback. Do you like this approach? Any
> suggestions?
> One thing I'm not sure about is MutableCSVFormat. Maybe this can be merged
> together with CSVFormatModifier.
>
> Regards,
> Benedikt
>
>
> [1] http://markmail.org/thread/o3s2a5hyj6xh4nzj
> [2] http://markmail.org/message/vjjdbckwr4dlqp2b
> [3] https://github.com/britter/apache-commons-csv-mirror
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>