[GUMP@vmgump]: Project commons-vfs2-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-vfs2-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 12 runs.
The current state of this project is 'Failed', with reason 'Build Timed Out'.
For reference only, the following projects are affected by this:
- commons-vfs2-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
 -INFO- Failed with reason build timed out
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_work/build_apache-commons_commons-vfs2-test.html
Work Name: build_apache-commons_commons-vfs2-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 mins
Command Line: /opt/maven3/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven3
-
Running org.apache.commons.vfs2.FileSystemExceptionTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.vfs2.FileTypeSelectorTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec
Running org.apache.commons.vfs2.FileIteratorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.vfs2.cache.LRUFilesCacheTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.159 sec
Running org.apache.commons.vfs2.cache.NullFilesCacheTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.119 sec
Running org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.119 sec
Running org.apache.commons.vfs2.util.EncryptDecryptTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.661 sec
Running org.apache.commons.vfs2.provider.zip.test.NestedZipTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.589 sec
Running org.apache.commons.vfs2.provider.zip.test.ZipProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.224 sec
Running org.apache.commons.vfs2.provider.jar.test.JarAttributesTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.248 sec
Running org.apache.commons.vfs2.provider.jar.test.JarProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.226 sec
Running org.apache.commons.vfs2.provider.ftp.test.FtpProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.487 sec
Running org.apache.commons.vfs2.provider.ftp.test.MultipleConnectionTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.061 sec
Running org.apache.commons.vfs2.provider.test.GenericFileNameTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.vfs2.provider.test.VirtualProviderTestCase
Tests run: 75, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.382 sec
Running org.apache.commons.vfs2.provider.test.FileObjectSortTestCase
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running org.apache.commons.vfs2.provider.url.test.UrlHttpProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.3 sec
Running org.apache.commons.vfs2.provider.url.test.UrlProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.389 sec
Running org.apache.commons.vfs2.provider.url.test.UrlProviderHttpTestCase
created threads still running:
#1: system  Keep-Alive-Timerdaemon  class 
sun.net.www.http.KeepAliveCache

Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.873 sec
Running org.apache.commons.vfs2.provider.http.test.GetContentInfoFunctionalTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.2 sec
Running org.apache.commons.vfs2.provider.http.test.HttpFilesCacheTestCase
Tests run: 1, 

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 136 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.252 sec
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO

Re: [chain2] Release Status

[Simone Tripodi]

Hi Elijah!!

nice to hear back from you!

If I recall correctly, we discussed two main topics before cutting the
first Release Candidate:

1) we agreed on dropping the confusing CatalogFactory, or at least
making it more user friendly

2) parser APIs change - there is a prototype patch on CHAIN-76 which
aims to drop Digester and adopt Jackson, in order to support multiple
formats - you spoke about YAML format to describe Chains, Jackson
would dinamically supply it (I mean, without adding new code!).
In the meanwhile, I started contributing to jackson to fill missing
parts (that I had to add in my Chain patch). I have to take a look if
latest Jackson releases contain my contribution and give another try
in Chain - the proposed patch is anyway a little far to be completed,
so I'll need your help to get it done!

All the best, have a nice day!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Oct 15, 2012 at 11:25 PM, Elijah Zupancic  wrote:
> Hi Simo and everyone else,
>
> I'm working on a project that I would like to bring in the release
> version of chain2 rather than the snapshot. What other things do we
> need to finish up on in order for us to cut a release?
>
> Thanks,
> -Elijah
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Some first steps to implementing LANG-637

[Duncan Jones]

On 1 October 2012 14:07, Duncan Jones  wrote:
> I've now uploaded a complete solution for LANG-637 (see
> commons-lang3-LANG-637-complete.patch in JIRA) and I would very much
> appreciate feedback on the design and implementation. I've already
> factored in comments from James C and Matt B.
>
> I leant heavily on the existing reflection work in EqualsBuilder when
> adding the same functionality to my DiffBuilder class. If any part of
> my code particularly requires review, it is that area. Not just in the
> implementation details, but in some of the design decisions
> (particularly whether it is correct to throw a CastClassException when
> the types are not suited for comparison).

Just wondering if no feedback is good feedback? I've got plenty of
time to add some improvements if anyone has any pointers. I'd love to
see this make its way into the 3.2 release.

Thanks,

Duncan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Some first steps to implementing LANG-637

[Gary Gregory]

On Tue, Oct 16, 2012 at 5:29 AM, Duncan Jones  wrote:

> On 1 October 2012 14:07, Duncan Jones  wrote:
> > I've now uploaded a complete solution for LANG-637 (see
> > commons-lang3-LANG-637-complete.patch in JIRA) and I would very much
> > appreciate feedback on the design and implementation. I've already
> > factored in comments from James C and Matt B.
> >
> > I leant heavily on the existing reflection work in EqualsBuilder when
> > adding the same functionality to my DiffBuilder class. If any part of
> > my code particularly requires review, it is that area. Not just in the
> > implementation details, but in some of the design decisions
> > (particularly whether it is correct to throw a CastClassException when
> > the types are not suited for comparison).
>
> Just wondering if no feedback is good feedback? I've got plenty of
> time to add some improvements if anyone has any pointers. I'd love to
> see this make its way into the 3.2 release.
>

I've been swamped with other work, sorry ;) In my case no feedback means
I've not looked at it.

G


> Thanks,
>
> Duncan
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1397903 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java

[Gary Gregory]

On Mon, Oct 15, 2012 at 11:10 AM, sebb  wrote:

> On 13 October 2012 18:18,   wrote:
> > Author: ggregory
> > Date: Sat Oct 13 17:18:56 2012
> > New Revision: 1397903
> >
> > URL: http://svn.apache.org/viewvc?rev=1397903&view=rev
> > Log:
> > In-line comment.
> >
> > Modified:
> >
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
> >
> > Modified:
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java?rev=1397903&r1=1397902&r2=1397903&view=diff
> >
> ==
> > ---
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
> (original)
> > +++
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
> Sat Oct 13 17:18:56 2012
> > @@ -264,6 +264,7 @@ public class CSVParser implements Iterab
> >  try {
> >  return nextRecord();
> >  } catch (final IOException e) {
> > +// This is not great, throw an ISE instead?
>
> Should flag such comments as // TODO ?
>

Done.

G

>
> Otherwise, they are difficult to find.
> >  throw new RuntimeException(e);
> >  }
> >  }
> >
> >
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1398164 - /commons/proper/commons-parent/trunk/pom.xml

[Gary Gregory]

On Mon, Oct 15, 2012 at 11:01 AM, sebb  wrote:

> On 15 October 2012 01:57,   wrote:
> > Author: ggregory
> > Date: Mon Oct 15 00:57:57 2012
> > New Revision: 1398164
> >
> > URL: http://svn.apache.org/viewvc?rev=1398164&view=rev
> > Log:
> > Backout: buildnumber-maven-plugin 1.2 -> buildnumber-maven-plugin 1.1.
>
> Why?
>

At the time, the files were not in Maven Central. Looks like they are there
now.

G


>
> > Modified:
> > commons/proper/commons-parent/trunk/pom.xml
> >
> > Modified: commons/proper/commons-parent/trunk/pom.xml
> > URL:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1398164&r1=1398163&r2=1398164&view=diff
> >
> ==
> > --- commons/proper/commons-parent/trunk/pom.xml (original)
> > +++ commons/proper/commons-parent/trunk/pom.xml Mon Oct 15 00:57:57 2012
> > @@ -343,7 +343,7 @@ http://svn.apache.org/repos/asf/commons/
> >  
> >org.codehaus.mojo
> >buildnumber-maven-plugin
> > -  1.2
> > +  1.1
> >  
> >  
> >org.codehaus.mojo
> > @@ -1131,7 +1131,7 @@ http://svn.apache.org/repos/asf/commons/
> >  2.9
> >  0.8
> >  2.8
> > -2.4
> > +2.8
> >  2.3
> >  2.5.1
> >  2.2
> >
> >
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1398164 - /commons/proper/commons-parent/trunk/pom.xml

[Gary Gregory]

And now:

[WARNING] The POM for org.codehaus.mojo:buildnumber-maven-plugin:jar:1.2 is
missing, no dependency information available

G

On Tue, Oct 16, 2012 at 7:53 AM, Gary Gregory wrote:

> On Mon, Oct 15, 2012 at 11:01 AM, sebb  wrote:
>
>> On 15 October 2012 01:57,   wrote:
>> > Author: ggregory
>> > Date: Mon Oct 15 00:57:57 2012
>> > New Revision: 1398164
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1398164&view=rev
>> > Log:
>> > Backout: buildnumber-maven-plugin 1.2 -> buildnumber-maven-plugin 1.1.
>>
>> Why?
>>
>
> At the time, the files were not in Maven Central. Looks like they are
> there now.
>
> G
>
>
>>
>> > Modified:
>> > commons/proper/commons-parent/trunk/pom.xml
>> >
>> > Modified: commons/proper/commons-parent/trunk/pom.xml
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1398164&r1=1398163&r2=1398164&view=diff
>> >
>> ==
>> > --- commons/proper/commons-parent/trunk/pom.xml (original)
>> > +++ commons/proper/commons-parent/trunk/pom.xml Mon Oct 15 00:57:57 2012
>> > @@ -343,7 +343,7 @@ http://svn.apache.org/repos/asf/commons/
>> >  
>> >org.codehaus.mojo
>> >buildnumber-maven-plugin
>> > -  1.2
>> > +  1.1
>> >  
>> >  
>> >org.codehaus.mojo
>> > @@ -1131,7 +1131,7 @@ http://svn.apache.org/repos/asf/commons/
>> >  2.9
>> >  0.8
>> >  2.8
>> > -2.4
>> > +2.8
>> >  2.3
>> >  2.5.1
>> >  2.2
>> >
>> >
>>
>> -
>> 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://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[csv] CSVFormat API names

[Gary Gregory]

Hi All:

The format object can configure various aspects of input and output
formatting.

With my recent addition of the Quote enum for [CSV-53], there are now two
aspects of quoting to configure: the quote character and the quote policy
(minimal, all, non-numeric, and none.) FYI, 'none' is currently not
implemented.

First, I changed (without consulting this list, and please accept my
apologies for this) the - IMO - cryptic and burdensome terminology of
"encapsulator" to "quote char", and added "quote policy":

- withQuoteChar(char)
- withQuotePolicy(Quote)

My intention here is that all Quote APIs start with "withQuote" followed by
what aspect of quoting is being configured.

Alternatively, we could have:

- withQuote(char)
- withQuotePolicy(Quote)

Which makes the API more consistent with the other char/Character based
properties:

- withEscape
- withDelimiter
- withLineSeparator
- withCommentStart

none of the above are post-fixed with a "Char" in the name.

As far as reading, for me, the "-r" names are OK because the they are nouns
(things): "a delimiter", "a line separator." But I do not talk about "an
escape" because that would be an act (think Alcatraz) as opposed to what we
have here: a character used to /perform/ escapes.

So I propose to change "escape" to "escape char" because "escaper" is not a
word.

The name "comment start" is not great also because it implies (to me) that
there is a "comment end" missing. So plain "comment" or "comment char"
would be better.

Circling back to "quote char" which I have the way it is now for the same
reason as for the "escape" property.

In summary, using *Char names is better IMO.

Discuss! :)

Gary

[CSV-53] https://issues.apache.org/jira/browse/CSV-53
-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [csv] CSVFormat API names

[Jörg Schaible]

Hi Gary,

Gary Gregory wrote:

> Hi All:
> 
> The format object can configure various aspects of input and output
> formatting.
> 
> With my recent addition of the Quote enum for [CSV-53], there are now two
> aspects of quoting to configure: the quote character and the quote policy
> (minimal, all, non-numeric, and none.) FYI, 'none' is currently not
> implemented.
> 
> First, I changed (without consulting this list, and please accept my
> apologies for this) the - IMO - cryptic and burdensome terminology of
> "encapsulator" to "quote char", and added "quote policy":
> 
> - withQuoteChar(char)
> - withQuotePolicy(Quote)
> 
> My intention here is that all Quote APIs start with "withQuote" followed
> by what aspect of quoting is being configured.
> 
> Alternatively, we could have:
> 
> - withQuote(char)
> - withQuotePolicy(Quote)

or

- withQuote(char)
- withQuote(Quote)

;-)

> Which makes the API more consistent with the other char/Character based
> properties:
> 
> - withEscape
> - withDelimiter
> - withLineSeparator
> - withCommentStart
> 
> none of the above are post-fixed with a "Char" in the name.
> 
> As far as reading, for me, the "-r" names are OK because the they are
> nouns (things): "a delimiter", "a line separator." But I do not talk about
> "an escape" because that would be an act (think Alcatraz) as opposed to
> what we have here: a character used to /perform/ escapes.
> 
> So I propose to change "escape" to "escape char" because "escaper" is not
> a word.
> 
> The name "comment start" is not great also because it implies (to me) that
> there is a "comment end" missing. So plain "comment" or "comment char"
> would be better.

Who said it has to be a single char?

.withEOLComment("//")


Same applies to the line separator:

.withLineSeparator("\n\r")

> Circling back to "quote char" which I have the way it is now for the same
> reason as for the "escape" property.
> 
> In summary, using *Char names is better IMO.

Only if it can be a single char only. If it can either be a single char or a 
String, I normally tend to use overloaded methods:

- withEOLComment(char)
- withEOLComment(CharSequence)

> Discuss! :)

Can or worms opened :))

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Simone Tripodi]

+1 to Jörg, that would be my recommendation as well!

my 0.02 cents,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Oct 16, 2012 at 3:14 PM, Jörg Schaible
 wrote:
> Hi Gary,
>
> Gary Gregory wrote:
>
>> Hi All:
>>
>> The format object can configure various aspects of input and output
>> formatting.
>>
>> With my recent addition of the Quote enum for [CSV-53], there are now two
>> aspects of quoting to configure: the quote character and the quote policy
>> (minimal, all, non-numeric, and none.) FYI, 'none' is currently not
>> implemented.
>>
>> First, I changed (without consulting this list, and please accept my
>> apologies for this) the - IMO - cryptic and burdensome terminology of
>> "encapsulator" to "quote char", and added "quote policy":
>>
>> - withQuoteChar(char)
>> - withQuotePolicy(Quote)
>>
>> My intention here is that all Quote APIs start with "withQuote" followed
>> by what aspect of quoting is being configured.
>>
>> Alternatively, we could have:
>>
>> - withQuote(char)
>> - withQuotePolicy(Quote)
>
> or
>
> - withQuote(char)
> - withQuote(Quote)
>
> ;-)
>
>> Which makes the API more consistent with the other char/Character based
>> properties:
>>
>> - withEscape
>> - withDelimiter
>> - withLineSeparator
>> - withCommentStart
>>
>> none of the above are post-fixed with a "Char" in the name.
>>
>> As far as reading, for me, the "-r" names are OK because the they are
>> nouns (things): "a delimiter", "a line separator." But I do not talk about
>> "an escape" because that would be an act (think Alcatraz) as opposed to
>> what we have here: a character used to /perform/ escapes.
>>
>> So I propose to change "escape" to "escape char" because "escaper" is not
>> a word.
>>
>> The name "comment start" is not great also because it implies (to me) that
>> there is a "comment end" missing. So plain "comment" or "comment char"
>> would be better.
>
> Who said it has to be a single char?
>
> .withEOLComment("//")
>
>
> Same applies to the line separator:
>
> .withLineSeparator("\n\r")
>
>> Circling back to "quote char" which I have the way it is now for the same
>> reason as for the "escape" property.
>>
>> In summary, using *Char names is better IMO.
>
> Only if it can be a single char only. If it can either be a single char or a
> String, I normally tend to use overloaded methods:
>
> - withEOLComment(char)
> - withEOLComment(CharSequence)
>
>> Discuss! :)
>
> Can or worms opened :))
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
wrote:

> Hi Gary,
>
> Gary Gregory wrote:
>
> > Hi All:
> >
> > The format object can configure various aspects of input and output
> > formatting.
> >
> > With my recent addition of the Quote enum for [CSV-53], there are now two
> > aspects of quoting to configure: the quote character and the quote policy
> > (minimal, all, non-numeric, and none.) FYI, 'none' is currently not
> > implemented.
> >
> > First, I changed (without consulting this list, and please accept my
> > apologies for this) the - IMO - cryptic and burdensome terminology of
> > "encapsulator" to "quote char", and added "quote policy":
> >
> > - withQuoteChar(char)
> > - withQuotePolicy(Quote)
> >
> > My intention here is that all Quote APIs start with "withQuote" followed
> > by what aspect of quoting is being configured.
> >
> > Alternatively, we could have:
> >
> > - withQuote(char)
> > - withQuotePolicy(Quote)
>
> or
>
> - withQuote(char)
> - withQuote(Quote)
>
> ;-)
>

Darn, I wish I knew you better to know if you were joking! :)

This would not be good IMO because you are configuring two different
aspects of the behavior. When I see the same API name with different
parameters, I think that they are the same and that the API just does
conversions.

We could consider making Quote a class instead of an enum and have it carry
a char and an enum, such that one object defines all quoting aspects. This
might be too normalized a design for something so simple though.


>
> > Which makes the API more consistent with the other char/Character based
> > properties:
> >
> > - withEscape
> > - withDelimiter
> > - withLineSeparator
> > - withCommentStart
> >
> > none of the above are post-fixed with a "Char" in the name.
> >
> > As far as reading, for me, the "-r" names are OK because the they are
> > nouns (things): "a delimiter", "a line separator." But I do not talk
> about
> > "an escape" because that would be an act (think Alcatraz) as opposed to
> > what we have here: a character used to /perform/ escapes.
> >
> > So I propose to change "escape" to "escape char" because "escaper" is not
> > a word.
> >
> > The name "comment start" is not great also because it implies (to me)
> that
> > there is a "comment end" missing. So plain "comment" or "comment char"
> > would be better.
>
> Who said it has to be a single char?
>

The current implementation does. ;)

Are comments even in any RFC?


>
> .withEOLComment("//")
>
>
> Same applies to the line separator:
>
> .withLineSeparator("\n\r")
>
> > Circling back to "quote char" which I have the way it is now for the same
> > reason as for the "escape" property.
> >
> > In summary, using *Char names is better IMO.
>
> Only if it can be a single char only. If it can either be a single char or
> a
> String, I normally tend to use overloaded methods:
>
> - withEOLComment(char)
> - withEOLComment(CharSequence)
>

If you want to add // to the mix, please start a different thread. I'm not
sure this is really needed. Do you have a real life use case?

Merci!
Gary


>
> > Discuss! :)
>
> Can or worms opened :))
>
> - Jörg
>
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
wrote:

> Hi Gary,
>
> Gary Gregory wrote:
>
> > Hi All:
> >
> > The format object can configure various aspects of input and output
> > formatting.
> >
> > With my recent addition of the Quote enum for [CSV-53], there are now two
> > aspects of quoting to configure: the quote character and the quote policy
> > (minimal, all, non-numeric, and none.) FYI, 'none' is currently not
> > implemented.
> >
> > First, I changed (without consulting this list, and please accept my
> > apologies for this) the - IMO - cryptic and burdensome terminology of
> > "encapsulator" to "quote char", and added "quote policy":
> >
> > - withQuoteChar(char)
> > - withQuotePolicy(Quote)
> >
> > My intention here is that all Quote APIs start with "withQuote" followed
> > by what aspect of quoting is being configured.
> >
> > Alternatively, we could have:
> >
> > - withQuote(char)
> > - withQuotePolicy(Quote)
>
> or
>
> - withQuote(char)
> - withQuote(Quote)
>
> ;-)
>
> > Which makes the API more consistent with the other char/Character based
> > properties:
> >
> > - withEscape
> > - withDelimiter
> > - withLineSeparator
> > - withCommentStart
> >
> > none of the above are post-fixed with a "Char" in the name.
> >
> > As far as reading, for me, the "-r" names are OK because the they are
> > nouns (things): "a delimiter", "a line separator." But I do not talk
> about
> > "an escape" because that would be an act (think Alcatraz) as opposed to
> > what we have here: a character used to /perform/ escapes.
> >
> > So I propose to change "escape" to "escape char" because "escaper" is not
> > a word.
> >
> > The name "comment start" is not great also because it implies (to me)
> that
> > there is a "comment end" missing. So plain "comment" or "comment char"
> > would be better.
>
> Who said it has to be a single char?
>
> .withEOLComment("//")
>
>
> Same applies to the line separator:
>
> .withLineSeparator("\n\r")
>

My mistake there, I should not have mentioned this API. LineSeparator is
nice because it matches the line.separator system property name.

Gary


>
> > Circling back to "quote char" which I have the way it is now for the same
> > reason as for the "escape" property.
> >
> > In summary, using *Char names is better IMO.
>
> Only if it can be a single char only. If it can either be a single char or
> a
> String, I normally tend to use overloaded methods:
>
> - withEOLComment(char)
> - withEOLComment(CharSequence)
>
> > Discuss! :)
>
> Can or worms opened :))
>
> - Jörg
>
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [csv] CSVFormat API names

[Jörg Schaible]

Gary Gregory wrote:

> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
> wrote:
> 
>> Hi Gary,
>>
>> Gary Gregory wrote:
>>
>> > Hi All:
>> >
>> > The format object can configure various aspects of input and output
>> > formatting.
>> >
>> > With my recent addition of the Quote enum for [CSV-53], there are now
>> > two aspects of quoting to configure: the quote character and the quote
>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is currently
>> > not implemented.
>> >
>> > First, I changed (without consulting this list, and please accept my
>> > apologies for this) the - IMO - cryptic and burdensome terminology of
>> > "encapsulator" to "quote char", and added "quote policy":
>> >
>> > - withQuoteChar(char)
>> > - withQuotePolicy(Quote)
>> >
>> > My intention here is that all Quote APIs start with "withQuote"
>> > followed by what aspect of quoting is being configured.
>> >
>> > Alternatively, we could have:
>> >
>> > - withQuote(char)
>> > - withQuotePolicy(Quote)
>>
>> or
>>
>> - withQuote(char)
>> - withQuote(Quote)
>>
>> ;-)
>>
> 
> Darn, I wish I knew you better to know if you were joking! :)
> 
> This would not be good IMO because you are configuring two different
> aspects of the behavior. When I see the same API name with different
> parameters, I think that they are the same and that the API just does
> conversions.
> 
> We could consider making Quote a class instead of an enum and have it
> carry a char and an enum, such that one object defines all quoting
> aspects. This might be too normalized a design for something so simple
> though.

Actually I did not had a closer look to the API. You're definitely right to 
use different names for different aspects. It does not make sense to 
overload just for fun.

> 
> 
>>
>> > Which makes the API more consistent with the other char/Character based
>> > properties:
>> >
>> > - withEscape
>> > - withDelimiter
>> > - withLineSeparator
>> > - withCommentStart
>> >
>> > none of the above are post-fixed with a "Char" in the name.
>> >
>> > As far as reading, for me, the "-r" names are OK because the they are
>> > nouns (things): "a delimiter", "a line separator." But I do not talk
>> about
>> > "an escape" because that would be an act (think Alcatraz) as opposed to
>> > what we have here: a character used to /perform/ escapes.
>> >
>> > So I propose to change "escape" to "escape char" because "escaper" is
>> > not a word.
>> >
>> > The name "comment start" is not great also because it implies (to me)
>> that
>> > there is a "comment end" missing. So plain "comment" or "comment char"
>> > would be better.
>>
>> Who said it has to be a single char?
>>
> 
> The current implementation does. ;)
> 
> Are comments even in any RFC?

Not that I am aware of.

>> .withEOLComment("//")
>>
>>
>> Same applies to the line separator:
>>
>> .withLineSeparator("\n\r")
>>
>> > Circling back to "quote char" which I have the way it is now for the
>> > same reason as for the "escape" property.
>> >
>> > In summary, using *Char names is better IMO.
>>
>> Only if it can be a single char only. If it can either be a single char
>> or a
>> String, I normally tend to use overloaded methods:
>>
>> - withEOLComment(char)
>> - withEOLComment(CharSequence)
>>
> 
> If you want to add // to the mix, please start a different thread. I'm not
> sure this is really needed. Do you have a real life use case?

People come up with all kind of "solutions" they are used to. CSV is brittle 
anyway, just because there is no "real" standard.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Matt Benson]

Random thoughts--no real context here, so no way to inline:

- "line separator" concept, while harmonizing with the line.separator
system property, might be better represented as "row separator" so as
not to imply that the parameter should be in any way limited to \r or
\n .  I would think the default for this would be the line.separator
property, however, and thus should take a String or CharSequence
(perhaps it already does, but there's been so much talk about char
parameters...).

- with* methods:  just something to think about here, but while we're
creating a fluent API, would e.g. #delimitedBy('\t') read more
fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
#withEscape('\\') ?

$0.02,
Matt

On Tue, Oct 16, 2012 at 8:53 AM, Jörg Schaible
 wrote:
> Gary Gregory wrote:
>
>> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
>> wrote:
>>
>>> Hi Gary,
>>>
>>> Gary Gregory wrote:
>>>
>>> > Hi All:
>>> >
>>> > The format object can configure various aspects of input and output
>>> > formatting.
>>> >
>>> > With my recent addition of the Quote enum for [CSV-53], there are now
>>> > two aspects of quoting to configure: the quote character and the quote
>>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is currently
>>> > not implemented.
>>> >
>>> > First, I changed (without consulting this list, and please accept my
>>> > apologies for this) the - IMO - cryptic and burdensome terminology of
>>> > "encapsulator" to "quote char", and added "quote policy":
>>> >
>>> > - withQuoteChar(char)
>>> > - withQuotePolicy(Quote)
>>> >
>>> > My intention here is that all Quote APIs start with "withQuote"
>>> > followed by what aspect of quoting is being configured.
>>> >
>>> > Alternatively, we could have:
>>> >
>>> > - withQuote(char)
>>> > - withQuotePolicy(Quote)
>>>
>>> or
>>>
>>> - withQuote(char)
>>> - withQuote(Quote)
>>>
>>> ;-)
>>>
>>
>> Darn, I wish I knew you better to know if you were joking! :)
>>
>> This would not be good IMO because you are configuring two different
>> aspects of the behavior. When I see the same API name with different
>> parameters, I think that they are the same and that the API just does
>> conversions.
>>
>> We could consider making Quote a class instead of an enum and have it
>> carry a char and an enum, such that one object defines all quoting
>> aspects. This might be too normalized a design for something so simple
>> though.
>
> Actually I did not had a closer look to the API. You're definitely right to
> use different names for different aspects. It does not make sense to
> overload just for fun.
>
>>
>>
>>>
>>> > Which makes the API more consistent with the other char/Character based
>>> > properties:
>>> >
>>> > - withEscape
>>> > - withDelimiter
>>> > - withLineSeparator
>>> > - withCommentStart
>>> >
>>> > none of the above are post-fixed with a "Char" in the name.
>>> >
>>> > As far as reading, for me, the "-r" names are OK because the they are
>>> > nouns (things): "a delimiter", "a line separator." But I do not talk
>>> about
>>> > "an escape" because that would be an act (think Alcatraz) as opposed to
>>> > what we have here: a character used to /perform/ escapes.
>>> >
>>> > So I propose to change "escape" to "escape char" because "escaper" is
>>> > not a word.
>>> >
>>> > The name "comment start" is not great also because it implies (to me)
>>> that
>>> > there is a "comment end" missing. So plain "comment" or "comment char"
>>> > would be better.
>>>
>>> Who said it has to be a single char?
>>>
>>
>> The current implementation does. ;)
>>
>> Are comments even in any RFC?
>
> Not that I am aware of.
>
>>> .withEOLComment("//")
>>>
>>>
>>> Same applies to the line separator:
>>>
>>> .withLineSeparator("\n\r")
>>>
>>> > Circling back to "quote char" which I have the way it is now for the
>>> > same reason as for the "escape" property.
>>> >
>>> > In summary, using *Char names is better IMO.
>>>
>>> Only if it can be a single char only. If it can either be a single char
>>> or a
>>> String, I normally tend to use overloaded methods:
>>>
>>> - withEOLComment(char)
>>> - withEOLComment(CharSequence)
>>>
>>
>> If you want to add // to the mix, please start a different thread. I'm not
>> sure this is really needed. Do you have a real life use case?
>
> People come up with all kind of "solutions" they are used to. CSV is brittle
> anyway, just because there is no "real" standard.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson  wrote:

> Random thoughts--no real context here, so no way to inline:
>
> - "line separator" concept, while harmonizing with the line.separator
> system property, might be better represented as "row separator" so as
> not to imply that the parameter should be in any way limited to \r or
> \n .  I would think the default for this would be the line.separator
> property, however, and thus should take a String or CharSequence
> (perhaps it already does, but there's been so much talk about char
> parameters...).
>

Now that you mention it, this should have been obvious as soon as we wrote
the test cases where a record is split over more than one line.

There is a difference between line number and record number which the API
tracks.

I propose to change "line separator" to "record separator". The default can
be line.separator.

Gary


>
> - with* methods:  just something to think about here, but while we're
> creating a fluent API, would e.g. #delimitedBy('\t') read more
> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
> #withEscape('\\') ?
>
> $0.02,
> Matt
>
> On Tue, Oct 16, 2012 at 8:53 AM, Jörg Schaible
>  wrote:
> > Gary Gregory wrote:
> >
> >> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
> >> wrote:
> >>
> >>> Hi Gary,
> >>>
> >>> Gary Gregory wrote:
> >>>
> >>> > Hi All:
> >>> >
> >>> > The format object can configure various aspects of input and output
> >>> > formatting.
> >>> >
> >>> > With my recent addition of the Quote enum for [CSV-53], there are now
> >>> > two aspects of quoting to configure: the quote character and the
> quote
> >>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is
> currently
> >>> > not implemented.
> >>> >
> >>> > First, I changed (without consulting this list, and please accept my
> >>> > apologies for this) the - IMO - cryptic and burdensome terminology of
> >>> > "encapsulator" to "quote char", and added "quote policy":
> >>> >
> >>> > - withQuoteChar(char)
> >>> > - withQuotePolicy(Quote)
> >>> >
> >>> > My intention here is that all Quote APIs start with "withQuote"
> >>> > followed by what aspect of quoting is being configured.
> >>> >
> >>> > Alternatively, we could have:
> >>> >
> >>> > - withQuote(char)
> >>> > - withQuotePolicy(Quote)
> >>>
> >>> or
> >>>
> >>> - withQuote(char)
> >>> - withQuote(Quote)
> >>>
> >>> ;-)
> >>>
> >>
> >> Darn, I wish I knew you better to know if you were joking! :)
> >>
> >> This would not be good IMO because you are configuring two different
> >> aspects of the behavior. When I see the same API name with different
> >> parameters, I think that they are the same and that the API just does
> >> conversions.
> >>
> >> We could consider making Quote a class instead of an enum and have it
> >> carry a char and an enum, such that one object defines all quoting
> >> aspects. This might be too normalized a design for something so simple
> >> though.
> >
> > Actually I did not had a closer look to the API. You're definitely right
> to
> > use different names for different aspects. It does not make sense to
> > overload just for fun.
> >
> >>
> >>
> >>>
> >>> > Which makes the API more consistent with the other char/Character
> based
> >>> > properties:
> >>> >
> >>> > - withEscape
> >>> > - withDelimiter
> >>> > - withLineSeparator
> >>> > - withCommentStart
> >>> >
> >>> > none of the above are post-fixed with a "Char" in the name.
> >>> >
> >>> > As far as reading, for me, the "-r" names are OK because the they are
> >>> > nouns (things): "a delimiter", "a line separator." But I do not talk
> >>> about
> >>> > "an escape" because that would be an act (think Alcatraz) as opposed
> to
> >>> > what we have here: a character used to /perform/ escapes.
> >>> >
> >>> > So I propose to change "escape" to "escape char" because "escaper" is
> >>> > not a word.
> >>> >
> >>> > The name "comment start" is not great also because it implies (to me)
> >>> that
> >>> > there is a "comment end" missing. So plain "comment" or "comment
> char"
> >>> > would be better.
> >>>
> >>> Who said it has to be a single char?
> >>>
> >>
> >> The current implementation does. ;)
> >>
> >> Are comments even in any RFC?
> >
> > Not that I am aware of.
> >
> >>> .withEOLComment("//")
> >>>
> >>>
> >>> Same applies to the line separator:
> >>>
> >>> .withLineSeparator("\n\r")
> >>>
> >>> > Circling back to "quote char" which I have the way it is now for the
> >>> > same reason as for the "escape" property.
> >>> >
> >>> > In summary, using *Char names is better IMO.
> >>>
> >>> Only if it can be a single char only. If it can either be a single char
> >>> or a
> >>> String, I normally tend to use overloaded methods:
> >>>
> >>> - withEOLComment(char)
> >>> - withEOLComment(CharSequence)
> >>>
> >>
> >> If you want to add // to the mix, please start a different thread. I'm
> not
> >> sure this is really needed. Do you have a real life use case?
> >
> > People come up with all kind of "solutions" the

Re: [csv] CSVFormat API names

[sebb]

On 16 October 2012 16:29, Gary Gregory  wrote:
> On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson  wrote:
>
>> Random thoughts--no real context here, so no way to inline:
>>
>> - "line separator" concept, while harmonizing with the line.separator
>> system property, might be better represented as "row separator" so as
>> not to imply that the parameter should be in any way limited to \r or
>> \n .  I would think the default for this would be the line.separator
>> property, however, and thus should take a String or CharSequence
>> (perhaps it already does, but there's been so much talk about char
>> parameters...).
>>
>
> Now that you mention it, this should have been obvious as soon as we wrote
> the test cases where a record is split over more than one line.
>
> There is a difference between line number and record number which the API
> tracks.
>
> I propose to change "line separator" to "record separator". The default can
> be line.separator.

OK.
I prefer record to row.

> Gary
>
>
>>
>> - with* methods:  just something to think about here, but while we're
>> creating a fluent API, would e.g. #delimitedBy('\t') read more
>> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
>> #withEscape('\\') ?
>>
>> $0.02,
>> Matt
>>
>> On Tue, Oct 16, 2012 at 8:53 AM, Jörg Schaible
>>  wrote:
>> > Gary Gregory wrote:
>> >
>> >> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
>> >> wrote:
>> >>
>> >>> Hi Gary,
>> >>>
>> >>> Gary Gregory wrote:
>> >>>
>> >>> > Hi All:
>> >>> >
>> >>> > The format object can configure various aspects of input and output
>> >>> > formatting.
>> >>> >
>> >>> > With my recent addition of the Quote enum for [CSV-53], there are now
>> >>> > two aspects of quoting to configure: the quote character and the
>> quote
>> >>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is
>> currently
>> >>> > not implemented.
>> >>> >
>> >>> > First, I changed (without consulting this list, and please accept my
>> >>> > apologies for this) the - IMO - cryptic and burdensome terminology of
>> >>> > "encapsulator" to "quote char", and added "quote policy":
>> >>> >
>> >>> > - withQuoteChar(char)
>> >>> > - withQuotePolicy(Quote)
>> >>> >
>> >>> > My intention here is that all Quote APIs start with "withQuote"
>> >>> > followed by what aspect of quoting is being configured.
>> >>> >
>> >>> > Alternatively, we could have:
>> >>> >
>> >>> > - withQuote(char)
>> >>> > - withQuotePolicy(Quote)
>> >>>
>> >>> or
>> >>>
>> >>> - withQuote(char)
>> >>> - withQuote(Quote)
>> >>>
>> >>> ;-)
>> >>>
>> >>
>> >> Darn, I wish I knew you better to know if you were joking! :)
>> >>
>> >> This would not be good IMO because you are configuring two different
>> >> aspects of the behavior. When I see the same API name with different
>> >> parameters, I think that they are the same and that the API just does
>> >> conversions.
>> >>
>> >> We could consider making Quote a class instead of an enum and have it
>> >> carry a char and an enum, such that one object defines all quoting
>> >> aspects. This might be too normalized a design for something so simple
>> >> though.
>> >
>> > Actually I did not had a closer look to the API. You're definitely right
>> to
>> > use different names for different aspects. It does not make sense to
>> > overload just for fun.
>> >
>> >>
>> >>
>> >>>
>> >>> > Which makes the API more consistent with the other char/Character
>> based
>> >>> > properties:
>> >>> >
>> >>> > - withEscape
>> >>> > - withDelimiter
>> >>> > - withLineSeparator
>> >>> > - withCommentStart
>> >>> >
>> >>> > none of the above are post-fixed with a "Char" in the name.
>> >>> >
>> >>> > As far as reading, for me, the "-r" names are OK because the they are
>> >>> > nouns (things): "a delimiter", "a line separator." But I do not talk
>> >>> about
>> >>> > "an escape" because that would be an act (think Alcatraz) as opposed
>> to
>> >>> > what we have here: a character used to /perform/ escapes.
>> >>> >
>> >>> > So I propose to change "escape" to "escape char" because "escaper" is
>> >>> > not a word.
>> >>> >
>> >>> > The name "comment start" is not great also because it implies (to me)
>> >>> that
>> >>> > there is a "comment end" missing. So plain "comment" or "comment
>> char"
>> >>> > would be better.
>> >>>
>> >>> Who said it has to be a single char?
>> >>>
>> >>
>> >> The current implementation does. ;)
>> >>
>> >> Are comments even in any RFC?
>> >
>> > Not that I am aware of.
>> >
>> >>> .withEOLComment("//")
>> >>>
>> >>>
>> >>> Same applies to the line separator:
>> >>>
>> >>> .withLineSeparator("\n\r")
>> >>>
>> >>> > Circling back to "quote char" which I have the way it is now for the
>> >>> > same reason as for the "escape" property.
>> >>> >
>> >>> > In summary, using *Char names is better IMO.
>> >>>
>> >>> Only if it can be a single char only. If it can either be a single char
>> >>> or a
>> >>> String, I normally tend to use overloaded methods:
>> >>>
>> >>> - withEOLComment(char)
>> >>> - withEOL

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 11:29 AM, Gary Gregory wrote:

> On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson wrote:
>
>> Random thoughts--no real context here, so no way to inline:
>>
>> - "line separator" concept, while harmonizing with the line.separator
>> system property, might be better represented as "row separator" so as
>> not to imply that the parameter should be in any way limited to \r or
>> \n .  I would think the default for this would be the line.separator
>> property, however, and thus should take a String or CharSequence
>> (perhaps it already does, but there's been so much talk about char
>> parameters...).
>>
>
> Now that you mention it, this should have been obvious as soon as we wrote
> the test cases where a record is split over more than one line.
>
> There is a difference between line number and record number which the API
> tracks.
>
> I propose to change "line separator" to "record separator". The default
> can be line.separator.
>
> Gary
>
>
>>
>> - with* methods:  just something to think about here, but while we're
>> creating a fluent API, would e.g. #delimitedBy('\t') read more
>> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
>> #withEscape('\\') ?
>>
>
I find that the combination of the fluent API style AND immutability of the
format class ugly because of the PRISTINE & DISABLED internal crud.

Why not just have DEFAULT and dump PRISTINE? Other formats should be based
on DEFAULT.

With PRISTINE, the door is open for a future format to not override
DISABLED and create a bug, as unlikely as it is.

Gary




>> $0.02,
>> Matt
>>
>> On Tue, Oct 16, 2012 at 8:53 AM, Jörg Schaible
>>  wrote:
>> > Gary Gregory wrote:
>> >
>> >> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
>> >> wrote:
>> >>
>> >>> Hi Gary,
>> >>>
>> >>> Gary Gregory wrote:
>> >>>
>> >>> > Hi All:
>> >>> >
>> >>> > The format object can configure various aspects of input and output
>> >>> > formatting.
>> >>> >
>> >>> > With my recent addition of the Quote enum for [CSV-53], there are
>> now
>> >>> > two aspects of quoting to configure: the quote character and the
>> quote
>> >>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is
>> currently
>> >>> > not implemented.
>> >>> >
>> >>> > First, I changed (without consulting this list, and please accept my
>> >>> > apologies for this) the - IMO - cryptic and burdensome terminology
>> of
>> >>> > "encapsulator" to "quote char", and added "quote policy":
>> >>> >
>> >>> > - withQuoteChar(char)
>> >>> > - withQuotePolicy(Quote)
>> >>> >
>> >>> > My intention here is that all Quote APIs start with "withQuote"
>> >>> > followed by what aspect of quoting is being configured.
>> >>> >
>> >>> > Alternatively, we could have:
>> >>> >
>> >>> > - withQuote(char)
>> >>> > - withQuotePolicy(Quote)
>> >>>
>> >>> or
>> >>>
>> >>> - withQuote(char)
>> >>> - withQuote(Quote)
>> >>>
>> >>> ;-)
>> >>>
>> >>
>> >> Darn, I wish I knew you better to know if you were joking! :)
>> >>
>> >> This would not be good IMO because you are configuring two different
>> >> aspects of the behavior. When I see the same API name with different
>> >> parameters, I think that they are the same and that the API just does
>> >> conversions.
>> >>
>> >> We could consider making Quote a class instead of an enum and have it
>> >> carry a char and an enum, such that one object defines all quoting
>> >> aspects. This might be too normalized a design for something so simple
>> >> though.
>> >
>> > Actually I did not had a closer look to the API. You're definitely
>> right to
>> > use different names for different aspects. It does not make sense to
>> > overload just for fun.
>> >
>> >>
>> >>
>> >>>
>> >>> > Which makes the API more consistent with the other char/Character
>> based
>> >>> > properties:
>> >>> >
>> >>> > - withEscape
>> >>> > - withDelimiter
>> >>> > - withLineSeparator
>> >>> > - withCommentStart
>> >>> >
>> >>> > none of the above are post-fixed with a "Char" in the name.
>> >>> >
>> >>> > As far as reading, for me, the "-r" names are OK because the they
>> are
>> >>> > nouns (things): "a delimiter", "a line separator." But I do not talk
>> >>> about
>> >>> > "an escape" because that would be an act (think Alcatraz) as
>> opposed to
>> >>> > what we have here: a character used to /perform/ escapes.
>> >>> >
>> >>> > So I propose to change "escape" to "escape char" because "escaper"
>> is
>> >>> > not a word.
>> >>> >
>> >>> > The name "comment start" is not great also because it implies (to
>> me)
>> >>> that
>> >>> > there is a "comment end" missing. So plain "comment" or "comment
>> char"
>> >>> > would be better.
>> >>>
>> >>> Who said it has to be a single char?
>> >>>
>> >>
>> >> The current implementation does. ;)
>> >>
>> >> Are comments even in any RFC?
>> >
>> > Not that I am aware of.
>> >
>> >>> .withEOLComment("//")
>> >>>
>> >>>
>> >>> Same applies to the line separator:
>> >>>
>> >>> .withLineSeparator("\n\r")
>> >>>
>> >>> > Circling back to "quote char" which 

Re: [csv] CSVFormat API names

[sebb]

On 16 October 2012 16:34, Gary Gregory  wrote:
> On Tue, Oct 16, 2012 at 11:29 AM, Gary Gregory wrote:
>
>> On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson wrote:
>>
>>> Random thoughts--no real context here, so no way to inline:
>>>
>>> - "line separator" concept, while harmonizing with the line.separator
>>> system property, might be better represented as "row separator" so as
>>> not to imply that the parameter should be in any way limited to \r or
>>> \n .  I would think the default for this would be the line.separator
>>> property, however, and thus should take a String or CharSequence
>>> (perhaps it already does, but there's been so much talk about char
>>> parameters...).
>>>
>>
>> Now that you mention it, this should have been obvious as soon as we wrote
>> the test cases where a record is split over more than one line.
>>
>> There is a difference between line number and record number which the API
>> tracks.
>>
>> I propose to change "line separator" to "record separator". The default
>> can be line.separator.
>>
>> Gary
>>
>>
>>>
>>> - with* methods:  just something to think about here, but while we're
>>> creating a fluent API, would e.g. #delimitedBy('\t') read more
>>> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
>>> #withEscape('\\') ?
>>>
>>
> I find that the combination of the fluent API style AND immutability of the
> format class ugly because of the PRISTINE & DISABLED internal crud.
>
> Why not just have DEFAULT and dump PRISTINE? Other formats should be based
> on DEFAULT.

No, because DEFAULT includes several settings that may not be required.

> With PRISTINE, the door is open for a future format to not override
> DISABLED and create a bug, as unlikely as it is.

With DEFAULT, the door is *already* open for bugs due to failure to
reset the unwanted settings.

It's not possible currently to create an instance without overriding
the DISABLED delimiter.

> Gary
>
>
>
>
>>> $0.02,
>>> Matt
>>>
>>> On Tue, Oct 16, 2012 at 8:53 AM, Jörg Schaible
>>>  wrote:
>>> > Gary Gregory wrote:
>>> >
>>> >> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
>>> >> wrote:
>>> >>
>>> >>> Hi Gary,
>>> >>>
>>> >>> Gary Gregory wrote:
>>> >>>
>>> >>> > Hi All:
>>> >>> >
>>> >>> > The format object can configure various aspects of input and output
>>> >>> > formatting.
>>> >>> >
>>> >>> > With my recent addition of the Quote enum for [CSV-53], there are
>>> now
>>> >>> > two aspects of quoting to configure: the quote character and the
>>> quote
>>> >>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is
>>> currently
>>> >>> > not implemented.
>>> >>> >
>>> >>> > First, I changed (without consulting this list, and please accept my
>>> >>> > apologies for this) the - IMO - cryptic and burdensome terminology
>>> of
>>> >>> > "encapsulator" to "quote char", and added "quote policy":
>>> >>> >
>>> >>> > - withQuoteChar(char)
>>> >>> > - withQuotePolicy(Quote)
>>> >>> >
>>> >>> > My intention here is that all Quote APIs start with "withQuote"
>>> >>> > followed by what aspect of quoting is being configured.
>>> >>> >
>>> >>> > Alternatively, we could have:
>>> >>> >
>>> >>> > - withQuote(char)
>>> >>> > - withQuotePolicy(Quote)
>>> >>>
>>> >>> or
>>> >>>
>>> >>> - withQuote(char)
>>> >>> - withQuote(Quote)
>>> >>>
>>> >>> ;-)
>>> >>>
>>> >>
>>> >> Darn, I wish I knew you better to know if you were joking! :)
>>> >>
>>> >> This would not be good IMO because you are configuring two different
>>> >> aspects of the behavior. When I see the same API name with different
>>> >> parameters, I think that they are the same and that the API just does
>>> >> conversions.
>>> >>
>>> >> We could consider making Quote a class instead of an enum and have it
>>> >> carry a char and an enum, such that one object defines all quoting
>>> >> aspects. This might be too normalized a design for something so simple
>>> >> though.
>>> >
>>> > Actually I did not had a closer look to the API. You're definitely
>>> right to
>>> > use different names for different aspects. It does not make sense to
>>> > overload just for fun.
>>> >
>>> >>
>>> >>
>>> >>>
>>> >>> > Which makes the API more consistent with the other char/Character
>>> based
>>> >>> > properties:
>>> >>> >
>>> >>> > - withEscape
>>> >>> > - withDelimiter
>>> >>> > - withLineSeparator
>>> >>> > - withCommentStart
>>> >>> >
>>> >>> > none of the above are post-fixed with a "Char" in the name.
>>> >>> >
>>> >>> > As far as reading, for me, the "-r" names are OK because the they
>>> are
>>> >>> > nouns (things): "a delimiter", "a line separator." But I do not talk
>>> >>> about
>>> >>> > "an escape" because that would be an act (think Alcatraz) as
>>> opposed to
>>> >>> > what we have here: a character used to /perform/ escapes.
>>> >>> >
>>> >>> > So I propose to change "escape" to "escape char" because "escaper"
>>> is
>>> >>> > not a word.
>>> >>> >
>>> >>> > The name "comment start" is not great also because it implies (to
>>> me)
>>> >>> that
>>> >>> > th

Re: [csv] CSVFormat API names

[Jörg Schaible]

Matt Benson wrote:

> Random thoughts--no real context here, so no way to inline:
> 
> - "line separator" concept, while harmonizing with the line.separator
> system property, might be better represented as "row separator" so as
> not to imply that the parameter should be in any way limited to \r or
> \n .  I would think the default for this would be the line.separator
> property, however, and thus should take a String or CharSequence
> (perhaps it already does, but there's been so much talk about char
> parameters...).
> 
> - with* methods:  just something to think about here, but while we're
> creating a fluent API, would e.g. #delimitedBy('\t') read more
> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
> #withEscape('\\') ?

+1, good idea!

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1398164 - /commons/proper/commons-parent/trunk/pom.xml

[sebb]

On 16 October 2012 12:55, Gary Gregory  wrote:
> And now:
>
> [WARNING] The POM for org.codehaus.mojo:buildnumber-maven-plugin:jar:1.2 is
> missing, no dependency information available

Seems to be OK now; CP updated.

> G
>
> On Tue, Oct 16, 2012 at 7:53 AM, Gary Gregory wrote:
>
>> On Mon, Oct 15, 2012 at 11:01 AM, sebb  wrote:
>>
>>> On 15 October 2012 01:57,   wrote:
>>> > Author: ggregory
>>> > Date: Mon Oct 15 00:57:57 2012
>>> > New Revision: 1398164
>>> >
>>> > URL: http://svn.apache.org/viewvc?rev=1398164&view=rev
>>> > Log:
>>> > Backout: buildnumber-maven-plugin 1.2 -> buildnumber-maven-plugin 1.1.
>>>
>>> Why?
>>>
>>
>> At the time, the files were not in Maven Central. Looks like they are
>> there now.
>>
>> G
>>
>>
>>>
>>> > Modified:
>>> > commons/proper/commons-parent/trunk/pom.xml
>>> >
>>> > Modified: commons/proper/commons-parent/trunk/pom.xml
>>> > URL:
>>> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1398164&r1=1398163&r2=1398164&view=diff
>>> >
>>> ==
>>> > --- commons/proper/commons-parent/trunk/pom.xml (original)
>>> > +++ commons/proper/commons-parent/trunk/pom.xml Mon Oct 15 00:57:57 2012
>>> > @@ -343,7 +343,7 @@ http://svn.apache.org/repos/asf/commons/
>>> >  
>>> >org.codehaus.mojo
>>> >buildnumber-maven-plugin
>>> > -  1.2
>>> > +  1.1
>>> >  
>>> >  
>>> >org.codehaus.mojo
>>> > @@ -1131,7 +1131,7 @@ http://svn.apache.org/repos/asf/commons/
>>> >  2.9
>>> >  0.8
>>> >  2.8
>>> > -2.4
>>> > +2.8
>>> >  2.3
>>> >  2.5.1
>>> >  2.2
>>> >
>>> >
>>>
>>> -
>>> 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://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[sebb]

On 16 October 2012 17:08, Jörg Schaible  wrote:
> Matt Benson wrote:
>
>> Random thoughts--no real context here, so no way to inline:
>>
>> - "line separator" concept, while harmonizing with the line.separator
>> system property, might be better represented as "row separator" so as
>> not to imply that the parameter should be in any way limited to \r or
>> \n .  I would think the default for this would be the line.separator
>> property, however, and thus should take a String or CharSequence
>> (perhaps it already does, but there's been so much talk about char
>> parameters...).
>>
>> - with* methods:  just something to think about here, but while we're
>> creating a fluent API, would e.g. #delimitedBy('\t') read more
>> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
>> #withEscape('\\') ?
>
> +1, good idea!

Not sure I agree.
The advantage of a common prefix is that they work well with IDEs.

Also I think it's confusing to have xxxBy and yyyWith.

> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Matt Benson]

On Tue, Oct 16, 2012 at 11:27 AM, sebb  wrote:
> On 16 October 2012 17:08, Jörg Schaible  wrote:
>> Matt Benson wrote:
>>
>>> Random thoughts--no real context here, so no way to inline:
>>>
>>> - "line separator" concept, while harmonizing with the line.separator
>>> system property, might be better represented as "row separator" so as
>>> not to imply that the parameter should be in any way limited to \r or
>>> \n .  I would think the default for this would be the line.separator
>>> property, however, and thus should take a String or CharSequence
>>> (perhaps it already does, but there's been so much talk about char
>>> parameters...).
>>>
>>> - with* methods:  just something to think about here, but while we're
>>> creating a fluent API, would e.g. #delimitedBy('\t') read more
>>> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
>>> #withEscape('\\') ?
>>
>> +1, good idea!
>
> Not sure I agree.
> The advantage of a common prefix is that they work well with IDEs.

I can appreciate that if you began to type "with"... the IDE could
show ten different things you could be trying to use, but I don't know
that I'd go so far as to call this "working well with" the IDE.

>
> Also I think it's confusing to have xxxBy and yyyWith.

Are these specific examples not the words you would actually use were
you having a discussion on the subject in English?  :P

Matt

>
>> - Jörg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[James Carman]

On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson  wrote:
>
> Are these specific examples not the words you would actually use were
> you having a discussion on the subject in English?  :P
>

Why not just support both?  The "with*" methods would just be aliases
for the more "natural language" method names.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Matt Benson]

On Tue, Oct 16, 2012 at 11:42 AM, James Carman
 wrote:
> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson  wrote:
>>
>> Are these specific examples not the words you would actually use were
>> you having a discussion on the subject in English?  :P
>>
>
> Why not just support both?  The "with*" methods would just be aliases
> for the more "natural language" method names.

Or vice versa, sounds reasonable.  :)

Matt

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Stephen Colebourne]

On 16 October 2012 17:44, Matt Benson  wrote:
> On Tue, Oct 16, 2012 at 11:42 AM, James Carman
>  wrote:
>> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson  wrote:
>>>
>>> Are these specific examples not the words you would actually use were
>>> you having a discussion on the subject in English?  :P
>>>
>>
>> Why not just support both?  The "with*" methods would just be aliases
>> for the more "natural language" method names.

I would categorise first in two
- mutable builders producing immutable objects
- immutable objects

The former should generally have short methods without prefixes, the
latter is more complex.

For the latter, as a general rule, I use
withXxx()/plusXxx()/minusXxx() for items that affect the state and
past participle for other methods that manipulate the object in other
ways:

// affects state (year/month/day)
 date = date.withYear(2012)
 date = date.plusYears(6)
// aftect multiple pieces of state, so past participle
 period = period.multipliedBy(6)
 period = period.negated()

This is simply an extension of when you might use setXxx() on a bean,
and when you might use a named method.

Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Benedikt Ritter]

2012/10/16 Stephen Colebourne :
> On 16 October 2012 17:44, Matt Benson  wrote:
>> On Tue, Oct 16, 2012 at 11:42 AM, James Carman
>>  wrote:
>>> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson  wrote:

 Are these specific examples not the words you would actually use were
 you having a discussion on the subject in English?  :P

>>>
>>> Why not just support both?  The "with*" methods would just be aliases
>>> for the more "natural language" method names.
>
> I would categorise first in two
> - mutable builders producing immutable objects
> - immutable objects
>

Implementing a builder for CSVFormat was discussed a while ago [1]. I
think it's the best solution, because the validate method can then
made private and no code outside the format has to worry about whether
a format is valid or not (right now CSV code calls validate on newly
created CSVFormat instances to make sure they are valid.).
Anyway there were voices against a builder because it would complicate
the API, so we never implemented something like that...

Benedikt

[1] http://markmail.org/thread/mmeoymd3cpq5jxfr

> The former should generally have short methods without prefixes, the
> latter is more complex.
>
> For the latter, as a general rule, I use
> withXxx()/plusXxx()/minusXxx() for items that affect the state and
> past participle for other methods that manipulate the object in other
> ways:
>
> // affects state (year/month/day)
>  date = date.withYear(2012)
>  date = date.plusYears(6)
> // aftect multiple pieces of state, so past participle
>  period = period.multipliedBy(6)
>  period = period.negated()
>
> This is simply an extension of when you might use setXxx() on a bean,
> and when you might use a named method.
>
> Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 11:43 AM, sebb  wrote:

> On 16 October 2012 16:34, Gary Gregory  wrote:
> > On Tue, Oct 16, 2012 at 11:29 AM, Gary Gregory  >wrote:
> >
> >> On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson  >wrote:
> >>
> >>> Random thoughts--no real context here, so no way to inline:
> >>>
> >>> - "line separator" concept, while harmonizing with the line.separator
> >>> system property, might be better represented as "row separator" so as
> >>> not to imply that the parameter should be in any way limited to \r or
> >>> \n .  I would think the default for this would be the line.separator
> >>> property, however, and thus should take a String or CharSequence
> >>> (perhaps it already does, but there's been so much talk about char
> >>> parameters...).
> >>>
> >>
> >> Now that you mention it, this should have been obvious as soon as we
> wrote
> >> the test cases where a record is split over more than one line.
> >>
> >> There is a difference between line number and record number which the
> API
> >> tracks.
> >>
> >> I propose to change "line separator" to "record separator".


Folks seem to like this one, it is now in SVN.


> The default
> >> can be line.separator.
>

I did not do this one as is it seems RFC4180 defines CR+LF as the record
separator as noted in the Javadoc for
org.apache.commons.csv.CSVFormat.DEFAULT.

Gary


> >>
> >> Gary
> >>
> >>
> >>>
> >>> - with* methods:  just something to think about here, but while we're
> >>> creating a fluent API, would e.g. #delimitedBy('\t') read more
> >>> fluently than #withDelimiter('\t') ?  #escapingWith('\\') vs.
> >>> #withEscape('\\') ?
> >>>
> >>
> > I find that the combination of the fluent API style AND immutability of
> the
> > format class ugly because of the PRISTINE & DISABLED internal crud.
> >
> > Why not just have DEFAULT and dump PRISTINE? Other formats should be
> based
> > on DEFAULT.
>
> No, because DEFAULT includes several settings that may not be required.
>
> > With PRISTINE, the door is open for a future format to not override
> > DISABLED and create a bug, as unlikely as it is.
>
> With DEFAULT, the door is *already* open for bugs due to failure to
> reset the unwanted settings.
>
> It's not possible currently to create an instance without overriding
> the DISABLED delimiter.
>
> > Gary
> >
> >
> >
> >
> >>> $0.02,
> >>> Matt
> >>>
> >>> On Tue, Oct 16, 2012 at 8:53 AM, Jörg Schaible
> >>>  wrote:
> >>> > Gary Gregory wrote:
> >>> >
> >>> >> On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
> >>> >> wrote:
> >>> >>
> >>> >>> Hi Gary,
> >>> >>>
> >>> >>> Gary Gregory wrote:
> >>> >>>
> >>> >>> > Hi All:
> >>> >>> >
> >>> >>> > The format object can configure various aspects of input and
> output
> >>> >>> > formatting.
> >>> >>> >
> >>> >>> > With my recent addition of the Quote enum for [CSV-53], there are
> >>> now
> >>> >>> > two aspects of quoting to configure: the quote character and the
> >>> quote
> >>> >>> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is
> >>> currently
> >>> >>> > not implemented.
> >>> >>> >
> >>> >>> > First, I changed (without consulting this list, and please
> accept my
> >>> >>> > apologies for this) the - IMO - cryptic and burdensome
> terminology
> >>> of
> >>> >>> > "encapsulator" to "quote char", and added "quote policy":
> >>> >>> >
> >>> >>> > - withQuoteChar(char)
> >>> >>> > - withQuotePolicy(Quote)
> >>> >>> >
> >>> >>> > My intention here is that all Quote APIs start with "withQuote"
> >>> >>> > followed by what aspect of quoting is being configured.
> >>> >>> >
> >>> >>> > Alternatively, we could have:
> >>> >>> >
> >>> >>> > - withQuote(char)
> >>> >>> > - withQuotePolicy(Quote)
> >>> >>>
> >>> >>> or
> >>> >>>
> >>> >>> - withQuote(char)
> >>> >>> - withQuote(Quote)
> >>> >>>
> >>> >>> ;-)
> >>> >>>
> >>> >>
> >>> >> Darn, I wish I knew you better to know if you were joking! :)
> >>> >>
> >>> >> This would not be good IMO because you are configuring two different
> >>> >> aspects of the behavior. When I see the same API name with different
> >>> >> parameters, I think that they are the same and that the API just
> does
> >>> >> conversions.
> >>> >>
> >>> >> We could consider making Quote a class instead of an enum and have
> it
> >>> >> carry a char and an enum, such that one object defines all quoting
> >>> >> aspects. This might be too normalized a design for something so
> simple
> >>> >> though.
> >>> >
> >>> > Actually I did not had a closer look to the API. You're definitely
> >>> right to
> >>> > use different names for different aspects. It does not make sense to
> >>> > overload just for fun.
> >>> >
> >>> >>
> >>> >>
> >>> >>>
> >>> >>> > Which makes the API more consistent with the other char/Character
> >>> based
> >>> >>> > properties:
> >>> >>> >
> >>> >>> > - withEscape
> >>> >>> > - withDelimiter
> >>> >>> > - withLineSeparator
> >>> >>> > - withCommentStart
> >>> >>> >
> >>> >>> > none of the above are post-fixed with a "Char" in the name.
> >>> >>> >
> >>

Re: [csv] CSVFormat API names

[James Carman]

On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory  wrote:
>
> I did not do this one as is it seems RFC4180 defines CR+LF as the record
> separator as noted in the Javadoc for
> org.apache.commons.csv.CSVFormat.DEFAULT.
>

That's where the name of this component gets confusing to me.  Since
it's called "CSV", it would make sense that we follow RFC 4180, which
defines the standard for comma-separated value files and thus the
default record separator would be CRLF.  However, we are allowing
users to define whatever format they want using properties of the
CSVFormat class (of course, if you use delimiter != ',', then it's not
really CSV).  So, what's the intent?  This is more of a
delimited-record format parser/writer component which supports CSV.
Thus, it is not really very well-named.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 3:38 PM, James Carman wrote:

> On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory 
> wrote:
> >
> > I did not do this one as is it seems RFC4180 defines CR+LF as the record
> > separator as noted in the Javadoc for
> > org.apache.commons.csv.CSVFormat.DEFAULT.
> >
>
> That's where the name of this component gets confusing to me.  Since
> it's called "CSV", it would make sense that we follow RFC 4180, which
> defines the standard for comma-separated value files and thus the
> default record separator would be CRLF.  However, we are allowing
> users to define whatever format they want using properties of the
> CSVFormat class (of course, if you use delimiter != ',', then it's not
> really CSV).  So, what's the intent?  This is more of a
> delimited-record format parser/writer component which supports CSV.
> Thus, it is not really very well-named.
>

Right! Tab delimited is common too. So... what's a better name?

Commons DSV (Delimiter-Separated Values)?
Commons Text Records?
Commons Text Table?

Gary


> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 3:38 PM, James Carman wrote:

> On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory 
> wrote:
> >
> > I did not do this one as is it seems RFC4180 defines CR+LF as the record
> > separator as noted in the Javadoc for
> > org.apache.commons.csv.CSVFormat.DEFAULT.
> >
>
> That's where the name of this component gets confusing to me.  Since
> it's called "CSV", it would make sense that we follow RFC 4180, which
> defines the standard for comma-separated value files and thus the
> default record separator would be CRLF.  However, we are allowing
> users to define whatever format they want using properties of the
> CSVFormat class (of course, if you use delimiter != ',', then it's not
> really CSV).  So, what's the intent?  This is more of a
> delimited-record format parser/writer component which supports CSV.
> Thus, it is not really very well-named.
>

Why not rename DEFAULT to RFC418?

Gary


> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [csv] CSVFormat API names

[Honton, Charles]

Wikipedia has "Delimiter separated text" and "Delimiter-separated values"
(http://en.wikipedia.org/wiki/Delimiter-separated_values)

This suggests that CsvFormat, Rfc4180Format, and TsvFormat could be final
classes extending DsvFormat.

chas

On 10/16/12 12:50 PM, "Gary Gregory"  wrote:

>On Tue, Oct 16, 2012 at 3:38 PM, James Carman
>wrote:
>
>> On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory 
>> wrote:
>> >
>> > I did not do this one as is it seems RFC4180 defines CR+LF as the
>>record
>> > separator as noted in the Javadoc for
>> > org.apache.commons.csv.CSVFormat.DEFAULT.
>> >
>>
>> That's where the name of this component gets confusing to me.  Since
>> it's called "CSV", it would make sense that we follow RFC 4180, which
>> defines the standard for comma-separated value files and thus the
>> default record separator would be CRLF.  However, we are allowing
>> users to define whatever format they want using properties of the
>> CSVFormat class (of course, if you use delimiter != ',', then it's not
>> really CSV).  So, what's the intent?  This is more of a
>> delimited-record format parser/writer component which supports CSV.
>> Thus, it is not really very well-named.
>>
>
>Right! Tab delimited is common too. So... what's a better name?
>
>Commons DSV (Delimiter-Separated Values)?
>Commons Text Records?
>Commons Text Table?
>
>Gary
>
>
>> -
>> 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://bit.ly/ECvg0
>Spring Batch in Action: http://bit.ly/bqpbCK
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne wrote:

> On 16 October 2012 17:44, Matt Benson  wrote:
> > On Tue, Oct 16, 2012 at 11:42 AM, James Carman
> >  wrote:
> >> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson 
> wrote:
> >>>
> >>> Are these specific examples not the words you would actually use were
> >>> you having a discussion on the subject in English?  :P
> >>>
> >>
> >> Why not just support both?  The "with*" methods would just be aliases
> >> for the more "natural language" method names.
>
> I would categorise first in two
> - mutable builders producing immutable objects
> - immutable objects
>
> The former should generally have short methods without prefixes, the
> latter is more complex.
>
> For the latter, as a general rule, I use
> withXxx()/plusXxx()/minusXxx() for items that affect the state and
> past participle for other methods that manipulate the object in other
> ways:
>
> // affects state (year/month/day)
>  date = date.withYear(2012)
>  date = date.plusYears(6)
> // aftect multiple pieces of state, so past participle
>  period = period.multipliedBy(6)
>  period = period.negated()
>
> This is simply an extension of when you might use setXxx() on a bean,
> and when you might use a named method.
>

I like the idea of two classes: CVSFormat and CVSFormatBuilder but...

My next question is: Does CVSFormat have any public constructors? If not,
the builder can throw exceptions when one of its methods is called and
validation fails. This is nice in the sense that the format object feels
more lightweight and has a simpler/shorter protocol. It also leaves room
for other builders to be added (to configured formats from config files for
example) without growing the format class itself.

If CVSFormat does have public constructors, then the format class still has
to do its own validation. What I gain is the choice of using a kitchen sink
constructor or the fluent builder API, I can choose my style.

If there are two classes, and I cannot build a format without a format
builder, then why not collapse the two classes into one?

Gary


> Stephen
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [csv] CSVFormat API names

[Benedikt Ritter]

2012/10/16 Gary Gregory :
> On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne 
> wrote:
>
>> On 16 October 2012 17:44, Matt Benson  wrote:
>> > On Tue, Oct 16, 2012 at 11:42 AM, James Carman
>> >  wrote:
>> >> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson 
>> wrote:
>> >>>
>> >>> Are these specific examples not the words you would actually use were
>> >>> you having a discussion on the subject in English?  :P
>> >>>
>> >>
>> >> Why not just support both?  The "with*" methods would just be aliases
>> >> for the more "natural language" method names.
>>
>> I would categorise first in two
>> - mutable builders producing immutable objects
>> - immutable objects
>>
>> The former should generally have short methods without prefixes, the
>> latter is more complex.
>>
>> For the latter, as a general rule, I use
>> withXxx()/plusXxx()/minusXxx() for items that affect the state and
>> past participle for other methods that manipulate the object in other
>> ways:
>>
>> // affects state (year/month/day)
>>  date = date.withYear(2012)
>>  date = date.plusYears(6)
>> // aftect multiple pieces of state, so past participle
>>  period = period.multipliedBy(6)
>>  period = period.negated()
>>
>> This is simply an extension of when you might use setXxx() on a bean,
>> and when you might use a named method.
>>
>
> I like the idea of two classes: CVSFormat and CVSFormatBuilder but...
>
> My next question is: Does CVSFormat have any public constructors? If not,
> the builder can throw exceptions when one of its methods is called and
> validation fails. This is nice in the sense that the format object feels
> more lightweight and has a simpler/shorter protocol. It also leaves room
> for other builders to be added (to configured formats from config files for
> example) without growing the format class itself.
>
> If CVSFormat does have public constructors, then the format class still has
> to do its own validation. What I gain is the choice of using a kitchen sink
> constructor or the fluent builder API, I can choose my style.
>
> If there are two classes, and I cannot build a format without a format
> builder, then why not collapse the two classes into one?
>

Hi Gary,

I agree. I'd favor to have no public constructors and a builder that
is an internal class of CSVFormat. Users create CSVFormatBuilders by
calling a static method on CSVFormat:

CSVFormat format =
CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build();

Where defaults() returns a builder that is initialized with (suprise)
the values of the default format. No need to call a validate method.

Benedikt

> Gary
>
>
>> Stephen
>>
>> -
>> 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://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[sebb]

On 16 October 2012 21:56, Benedikt Ritter  wrote:
> 2012/10/16 Gary Gregory :
>> On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne 
>> wrote:
>>
>>> On 16 October 2012 17:44, Matt Benson  wrote:
>>> > On Tue, Oct 16, 2012 at 11:42 AM, James Carman
>>> >  wrote:
>>> >> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson 
>>> wrote:
>>> >>>
>>> >>> Are these specific examples not the words you would actually use were
>>> >>> you having a discussion on the subject in English?  :P
>>> >>>
>>> >>
>>> >> Why not just support both?  The "with*" methods would just be aliases
>>> >> for the more "natural language" method names.
>>>
>>> I would categorise first in two
>>> - mutable builders producing immutable objects
>>> - immutable objects
>>>
>>> The former should generally have short methods without prefixes, the
>>> latter is more complex.
>>>
>>> For the latter, as a general rule, I use
>>> withXxx()/plusXxx()/minusXxx() for items that affect the state and
>>> past participle for other methods that manipulate the object in other
>>> ways:
>>>
>>> // affects state (year/month/day)
>>>  date = date.withYear(2012)
>>>  date = date.plusYears(6)
>>> // aftect multiple pieces of state, so past participle
>>>  period = period.multipliedBy(6)
>>>  period = period.negated()
>>>
>>> This is simply an extension of when you might use setXxx() on a bean,
>>> and when you might use a named method.
>>>
>>
>> I like the idea of two classes: CVSFormat and CVSFormatBuilder but...
>>
>> My next question is: Does CVSFormat have any public constructors? If not,
>> the builder can throw exceptions when one of its methods is called and
>> validation fails. This is nice in the sense that the format object feels
>> more lightweight and has a simpler/shorter protocol. It also leaves room
>> for other builders to be added (to configured formats from config files for
>> example) without growing the format class itself.
>>
>> If CVSFormat does have public constructors, then the format class still has
>> to do its own validation. What I gain is the choice of using a kitchen sink
>> constructor or the fluent builder API, I can choose my style.
>>
>> If there are two classes, and I cannot build a format without a format
>> builder, then why not collapse the two classes into one?
>>
>
> Hi Gary,
>
> I agree. I'd favor to have no public constructors and a builder that
> is an internal class of CSVFormat. Users create CSVFormatBuilders by
> calling a static method on CSVFormat:
>
> CSVFormat format =
> CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build();
>
> Where defaults() returns a builder that is initialized with (suprise)
> the values of the default format. No need to call a validate method.

If you mean that the build method does the validation, then I agree.
I think validation is necessary to check that the defined
meta-characters are distinct.

We could ignore validation and let the user define
escape=delimiter=quote , but I suspect that would generate a lot of
unnecessary user queries when things then go wrong in odd ways.

> Benedikt
>
>> Gary
>>
>>
>>> Stephen
>>>
>>> -
>>> 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://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[sebb]

On 16 October 2012 21:00, Gary Gregory  wrote:
> On Tue, Oct 16, 2012 at 3:38 PM, James Carman 
> wrote:
>
>> On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory 
>> wrote:
>> >
>> > I did not do this one as is it seems RFC4180 defines CR+LF as the record
>> > separator as noted in the Javadoc for
>> > org.apache.commons.csv.CSVFormat.DEFAULT.
>> >
>>
>> That's where the name of this component gets confusing to me.  Since
>> it's called "CSV", it would make sense that we follow RFC 4180, which
>> defines the standard for comma-separated value files and thus the
>> default record separator would be CRLF.  However, we are allowing
>> users to define whatever format they want using properties of the
>> CSVFormat class (of course, if you use delimiter != ',', then it's not
>> really CSV).  So, what's the intent?  This is more of a
>> delimited-record format parser/writer component which supports CSV.
>> Thus, it is not really very well-named.

CSV could stand for Character Separated Variables.

Although CSV usually means comma-separated, I think it is treated as a
generic name sufficiently often that the it is not likely to be a big
problem.

The difficulty with all the other names is that they are not at all well known.

>>
>
> Why not rename DEFAULT to RFC418?

I agree that DEFAULT is a poor name, but could not get agreement to
change it previously.

There is already an RFC4180; DEFAULT is RFC4180 + allow blank lines.

> Gary
>
>
>> -
>> 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://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [csv] CSVFormat API names

[Gary Gregory]

On Tue, Oct 16, 2012 at 7:14 PM, sebb  wrote:

> On 16 October 2012 21:00, Gary Gregory  wrote:
> > On Tue, Oct 16, 2012 at 3:38 PM, James Carman <
> ja...@carmanconsulting.com>wrote:
> >
> >> On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory 
> >> wrote:
> >> >
> >> > I did not do this one as is it seems RFC4180 defines CR+LF as the
> record
> >> > separator as noted in the Javadoc for
> >> > org.apache.commons.csv.CSVFormat.DEFAULT.
> >> >
> >>
> >> That's where the name of this component gets confusing to me.  Since
> >> it's called "CSV", it would make sense that we follow RFC 4180, which
> >> defines the standard for comma-separated value files and thus the
> >> default record separator would be CRLF.  However, we are allowing
> >> users to define whatever format they want using properties of the
> >> CSVFormat class (of course, if you use delimiter != ',', then it's not
> >> really CSV).  So, what's the intent?  This is more of a
> >> delimited-record format parser/writer component which supports CSV.
> >> Thus, it is not really very well-named.
>
> CSV could stand for Character Separated Variables.
>

Ah... very clever. TLA overloading, I love it!

Gary


>
> Although CSV usually means comma-separated, I think it is treated as a
> generic name sufficiently often that the it is not likely to be a big
> problem.
>
> The difficulty with all the other names is that they are not at all well
> known.
>
> >>
> >
> > Why not rename DEFAULT to RFC418?
>
> I agree that DEFAULT is a poor name, but could not get agreement to
> change it previously.
>
> There is already an RFC4180; DEFAULT is RFC4180 + allow blank lines.
>
> > Gary
> >
> >
> >> -
> >> 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://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> 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://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory