[
https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226880#comment-13226880
]
Oliver Heger commented on CSV-43:
---------------------------------
Wouldn't this be a good candidate for the builder pattern (Bloch, Effective
Java, item 2)? The nested Builder class implements the fluent interface and
eventually creates an immutable instance of CSVFormat. Maybe, as an extension,
the Builder could be seeded with an existing CSVFormat instance if a new
instance is to be derived from an existing one.
> CSVFormat fluent API is rather inefficient
> ------------------------------------------
>
> Key: CSV-43
> URL: https://issues.apache.org/jira/browse/CSV-43
> Project: Commons CSV
> Issue Type: Improvement
> Reporter: Sebb
>
> The implementation of the CSVFormat fluent API is rather inefficient, as each
> method invocation clones the original class instance.
> Now that the fields are volatile, it would be possible to do away with the
> clone() calls entirely.
> This would mean that the format could be updated later.
> If such usage is not desirable, then perhaps consider adding some kind of
> "freeze" method to prevent further changes.
> Or perhaps the parse() and format() methods could perform the freeze (e.g.
> set a flag to disable further updates).
--
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
