[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231369#comment-13231369
]
Sebb commented on CSV-68:
-------------------------
bq. how about renaming init(char) to withDelimiter(char)
The delimiter is different, in that it is the only parameter that must be
specified.
But one could still potentially have a withDelimiter() method that could be
applied to an existing Builder chain, e.g. to modify an existing format. [The
builder delim field is final. I might well change that and add the method.]
Note that the first and last methods in the chain have different input/output
classes, so should use a different naming convention.
"CSVFormat.init()" could be replaced by "new CSVFormat.Builder()" but I thought
it was slightly neater to have a static "newInstance()" method, and given that
the delimiter needs to be defined, I thought it might as well be a parameter to
the init() method.
The init() method can of course be renamed.
It cannot be renamed to withDelimiter() unless the existing method of the same
name is dropped; but even without the name clash I think it would be a mistake
to use a name prefixed "with" as the "newInstance" method as users would expect
to be able to provide the parameters in any order.
Just realised that this would also be possible if each withMethod were defined
as a static method in CSVFormat as well as a class method in the Builder. [Only
the build() method would be unique to the Builder.]
The only extra method call required would then be the build() method.
So the syntax would be
{code}
CSVFormat.withDelimiter(',').withEncapsulator('"')...build();
CSVFormat.excel().withDelimiter(';').build();
{code}
Maybe that would satisfy everyone?
> Use Builder pattern for CSVFormat
> ---------------------------------
>
> Key: CSV-68
> URL: https://issues.apache.org/jira/browse/CSV-68
> Project: Commons CSV
> Issue Type: Improvement
> Reporter: Sebb
> Attachments: CSV-68.patch
>
>
> Using a builder pattern to create CSVFormat instances would allow the
> settings to be validated at creation time and would eliminate the need to
> keep creating new CSVFormat instances whilst still allowing the class to be
> immutable.
> A possible API is as follows:
> {code}
> CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
> .withEncapsulator('"')
> .withLeadingSpacesIgnored(true)
> .withTrailingSpacesIgnored(true)
> .withEmptyLinesIgnored(true)
> .withLineSeparator("\r\n") // optional, as it would be the default
> .build();
> CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
> with pre-defined format
> .withSurroundingSpacesIgnored(false)
> .build();
> {code}
> Compare this with the current syntax:
> {code}
> // internal syntax; not easy to determine what all the parameters do
> CSVFormat DEFAULT1 = new CSVFormat(',', '"', DISABLED, DISABLED, true, true,
> false, true, CRLF);
> // external syntax
> CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
> {code}
> As a proof of concept I've written skeleton code which compiles (but needs
> completing).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
