Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 15 Nov 2012 21:19:12 +0000 (UTC)
From: "Benedikt Ritter (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <68095068.121075.1353014352994.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1542391558.22615.1331862514729.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CSV-68) Use the Builder pattern for CSVFormat
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benedikt Ritter updated CSV-68:
-------------------------------

    Attachment: CSV-68_20121115.patch

I have added a method that lets you initialize a CSVFormatBuilder with the values of a given CSVFormat. I also included two tests methods. There is a FIXME left in CSVFormatBuilderTest, because CSVFormat does not implement equals. After equals is implemented Assert.assertEquals(Object, Object) can be used to validate that the copied CSVFormat is equal to the one passed in.

Now I wonder if it is a good idea to simply pass format.header to the CSVFormatBuilder in 441. This makes it possible to let a reference to the header array escape to the calling code. Maybe we have to create copy of the array? The same applies to all the other non primitive parameters.

Best regards,
Benedikt
                
> Use the 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_20121111.patch, CSV-68_20121114.patch, CSV-68_20121115.patch, CSV-68.patch, CSVFormat2.java, CVSFormat2Main.java
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira