Am 09.04.2013 08:48, schrieb Benedikt Ritter:
2013/4/8 Emmanuel Bourg <ebo...@apache.org>
Le 08/04/2013 22:39, Gary Gregory a écrit :
But that's the price for immutability for some of these objects.
Not sure, we already achieved immutability last year without paying this
price:
http://svn.apache.org/repos/asf/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?p=1305548
This design was sacrified for the sake of implementing a "by the book"
builder pattern that brings no real benefit in term of usability. It's
just a useless layer of complexity.
You're right, the old impl was already immutable. The problem was, that it
was not possible for a CSVFormat to validate itself at construction time.
We had to call the package private validate() method. I think we have been
through this several times. All arguments have been exchanged. If there is
a way to let a CSVFormat validate itself by the time it is constructed with
the old AP, I'm more than happy to drop the builder.
This is not about implementing "by the book" builder patterns.
Not sure whether this is worth the effort, but maybe as an academic
exercise in defining DSLs with Java:
Would an approach like the following one be acceptable from an API
user's point of view:
CSVFormat newFormat = CSVFormat.DEFAULT.derive(
withDelimiter('!'), withNullString("NULL"));
Here the derive() method expects a number of FormatManipulator objects
as varargs argument. The withXXX() methods are static methods either in
CSVFormat or a separate helper class creating concrete FormatManipulator
implementations.
derive() creates a mutable format definition object based on its current
state. It iterates over its arguments passing each the format definition
object. Concrete manipulator implementations update it accordingly. At
the end, the resulting format definition is validated, and a new
immutable CSVFormat is created from it.
This is obviously some implementation effort. It requires less code for
the user of the API. The approach is extensible, new properties can be
added by providing new manipulator implementations and static
convenience methods for creating them.
Oliver
Benedikt
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
