[GUMP@vmgump]: Project commons-vfs2-test (in module apache-commons) failed
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
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 misplaced 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 foo 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 bar 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 datamodel 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 data 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 baz 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]
Re: [chain2] Release Status
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 eli...@apache.org 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
On 1 October 2012 14:07, Duncan Jones dun...@wortharead.com 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
On Tue, Oct 16, 2012 at 5:29 AM, Duncan Jones dun...@wortharead.com wrote: On 1 October 2012 14:07, Duncan Jones dun...@wortharead.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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
On Mon, Oct 15, 2012 at 11:10 AM, sebb seb...@gmail.com wrote:
On 13 October 2012 18:18, ggreg...@apache.org wrote:
Author: ggregory
Date: Sat Oct 13 17:18:56 2012
New Revision: 1397903
URL: http://svn.apache.org/viewvc?rev=1397903view=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=1397903r1=1397902r2=1397903view=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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://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
On Mon, Oct 15, 2012 at 11:01 AM, sebb seb...@gmail.com wrote: On 15 October 2012 01:57, ggreg...@apache.org wrote: Author: ggregory Date: Mon Oct 15 00:57:57 2012 New Revision: 1398164 URL: http://svn.apache.org/viewvc?rev=1398164view=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=1398164r1=1398163r2=1398164view=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/ plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId - version1.2/version + version1.1/version /plugin plugin groupIdorg.codehaus.mojo/groupId @@ -1131,7 +1131,7 @@ http://svn.apache.org/repos/asf/commons/ commons.javadoc.version2.9/commons.javadoc.version commons.rat.version0.8/commons.rat.version commons.changes.version2.8/commons.changes.version -commons.clirr.version2.4/commons.clirr.version +commons.clirr.version2.8/commons.clirr.version commons.jxr.version2.3/commons.jxr.version commons.project-info.version2.5.1/commons.project-info.version commons.wagon-ssh.version2.2/commons.wagon-ssh.version - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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
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 garydgreg...@gmail.comwrote: On Mon, Oct 15, 2012 at 11:01 AM, sebb seb...@gmail.com wrote: On 15 October 2012 01:57, ggreg...@apache.org wrote: Author: ggregory Date: Mon Oct 15 00:57:57 2012 New Revision: 1398164 URL: http://svn.apache.org/viewvc?rev=1398164view=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=1398164r1=1398163r2=1398164view=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/ plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId - version1.2/version + version1.1/version /plugin plugin groupIdorg.codehaus.mojo/groupId @@ -1131,7 +1131,7 @@ http://svn.apache.org/repos/asf/commons/ commons.javadoc.version2.9/commons.javadoc.version commons.rat.version0.8/commons.rat.version commons.changes.version2.8/commons.changes.version -commons.clirr.version2.4/commons.clirr.version +commons.clirr.version2.8/commons.clirr.version commons.jxr.version2.3/commons.jxr.version commons.project-info.version2.5.1/commons.project-info.version commons.wagon-ssh.version2.2/commons.wagon-ssh.version - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[csv] CSVFormat API names
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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] CSVFormat API names
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
+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 joerg.schai...@scalaris.com 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
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible joerg.schai...@scalaris.comwrote: 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] CSVFormat API names
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible joerg.schai...@scalaris.comwrote: 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] CSVFormat API names
Gary Gregory wrote: On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible joerg.schai...@scalaris.comwrote: 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
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
joerg.schai...@scalaris.com wrote:
Gary Gregory wrote:
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
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
On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson gudnabr...@gmail.com 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
joerg.schai...@scalaris.com wrote:
Gary Gregory wrote:
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
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:
Re: [csv] CSVFormat API names
On 16 October 2012 16:29, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson gudnabr...@gmail.com 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
joerg.schai...@scalaris.com wrote:
Gary Gregory wrote:
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
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
On Tue, Oct 16, 2012 at 11:29 AM, Gary Gregory garydgreg...@gmail.comwrote:
On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson gudnabr...@gmail.comwrote:
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
joerg.schai...@scalaris.com wrote:
Gary Gregory wrote:
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
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
Re: [csv] CSVFormat API names
On 16 October 2012 16:34, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:29 AM, Gary Gregory garydgreg...@gmail.comwrote:
On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson gudnabr...@gmail.comwrote:
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
joerg.schai...@scalaris.com wrote:
Gary Gregory wrote:
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
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
Re: [csv] CSVFormat API names
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
On 16 October 2012 12:55, Gary Gregory garydgreg...@gmail.com 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 garydgreg...@gmail.comwrote: On Mon, Oct 15, 2012 at 11:01 AM, sebb seb...@gmail.com wrote: On 15 October 2012 01:57, ggreg...@apache.org wrote: Author: ggregory Date: Mon Oct 15 00:57:57 2012 New Revision: 1398164 URL: http://svn.apache.org/viewvc?rev=1398164view=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=1398164r1=1398163r2=1398164view=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/ plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId - version1.2/version + version1.1/version /plugin plugin groupIdorg.codehaus.mojo/groupId @@ -1131,7 +1131,7 @@ http://svn.apache.org/repos/asf/commons/ commons.javadoc.version2.9/commons.javadoc.version commons.rat.version0.8/commons.rat.version commons.changes.version2.8/commons.changes.version -commons.clirr.version2.4/commons.clirr.version +commons.clirr.version2.8/commons.clirr.version commons.jxr.version2.3/commons.jxr.version commons.project-info.version2.5.1/commons.project-info.version commons.wagon-ssh.version2.2/commons.wagon-ssh.version - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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
On 16 October 2012 17:08, Jörg Schaible joerg.schai...@gmx.de 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
On Tue, Oct 16, 2012 at 11:27 AM, sebb seb...@gmail.com wrote:
On 16 October 2012 17:08, Jörg Schaible joerg.schai...@gmx.de 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
On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com 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
On Tue, Oct 16, 2012 at 11:42 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com 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
On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote: On Tue, Oct 16, 2012 at 11:42 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com 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
2012/10/16 Stephen Colebourne scolebou...@joda.org: On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote: On Tue, Oct 16, 2012 at 11:42 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com 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
On Tue, Oct 16, 2012 at 11:43 AM, sebb seb...@gmail.com wrote:
On 16 October 2012 16:34, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:29 AM, Gary Gregory garydgreg...@gmail.com
wrote:
On Tue, Oct 16, 2012 at 11:04 AM, Matt Benson gudnabr...@gmail.com
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
joerg.schai...@scalaris.com wrote:
Gary Gregory wrote:
On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
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
Re: [csv] CSVFormat API names
On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory garydgreg...@gmail.com 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
On Tue, Oct 16, 2012 at 3:38 PM, James Carman ja...@carmanconsulting.comwrote: On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory garydgreg...@gmail.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] CSVFormat API names
On Tue, Oct 16, 2012 at 3:38 PM, James Carman ja...@carmanconsulting.comwrote: On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory garydgreg...@gmail.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] CSVFormat API names
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 garydgreg...@gmail.com wrote: On Tue, Oct 16, 2012 at 3:38 PM, James Carman ja...@carmanconsulting.comwrote: On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory garydgreg...@gmail.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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
On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne scolebou...@joda.orgwrote: On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote: On Tue, Oct 16, 2012 at 11:42 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [csv] CSVFormat API names
2012/10/16 Gary Gregory garydgreg...@gmail.com:
On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne
scolebou...@joda.orgwrote:
On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:42 AM, James Carman
ja...@carmanconsulting.com wrote:
On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com
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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://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
On 16 October 2012 21:56, Benedikt Ritter benerit...@gmail.com wrote:
2012/10/16 Gary Gregory garydgreg...@gmail.com:
On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne
scolebou...@joda.orgwrote:
On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote:
On Tue, Oct 16, 2012 at 11:42 AM, James Carman
ja...@carmanconsulting.com wrote:
On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com
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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://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
On 16 October 2012 21:00, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Oct 16, 2012 at 3:38 PM, James Carman ja...@carmanconsulting.comwrote: On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory garydgreg...@gmail.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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
On Tue, Oct 16, 2012 at 7:14 PM, sebb seb...@gmail.com wrote: On 16 October 2012 21:00, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Oct 16, 2012 at 3:38 PM, James Carman ja...@carmanconsulting.comwrote: On Tue, Oct 16, 2012 at 2:25 PM, Gary Gregory garydgreg...@gmail.com 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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
