2013/4/10 Oliver Heger <oliver.he...@oliver-heger.de>
> 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<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"));
>
I like this. With a slight twist it would become even shorter:
CSVFormat newFormat = CSVFormat.DEFAULT.with(
delimiter('!'), nullString("NULL"));
This may even help with CSV-78 [1] because we could do something like:
CSVFormat newFormat = CSVFormat.DEFAULT.with(noEscape());
>
> 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.
>
Yep this does seem to be a little more complex. But if we can satisfy all
people involved here and create a good API from a user POV it is worth the
effort IMHO.
Thank you very much for bringing in a fresh new idea in this disussion!
Benedikt
[1] https://issues.apache.org/jira/browse/CSV-78
>
> Oliver
>
>
>> Benedikt
>>
>>
>>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>>
>>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
