On 16 October 2012 21:56, Benedikt Ritter <benerit...@gmail.com> wrote:
> 2012/10/16 Gary Gregory <garydgreg...@gmail.com>:
>> On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne
>> <scolebou...@joda.org>wrote:
>>
>>> On 16 October 2012 17:44, Matt Benson <gudnabr...@gmail.com> wrote:
>>> > On Tue, Oct 16, 2012 at 11:42 AM, James Carman
>>> > <ja...@carmanconsulting.com> wrote:
>>> >> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson <gudnabr...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> Are these specific examples not the words you would actually use were
>>> >>> you having a discussion on the subject in English? :P
>>> >>>
>>> >>
>>> >> Why not just support both? The "with*" methods would just be aliases
>>> >> for the more "natural language" method names.
>>>
>>> I would categorise first in two
>>> - mutable builders producing immutable objects
>>> - immutable objects
>>>
>>> The former should generally have short methods without prefixes, the
>>> latter is more complex.
>>>
>>> For the latter, as a general rule, I use
>>> withXxx()/plusXxx()/minusXxx() for items that affect the state and
>>> past participle for other methods that manipulate the object in other
>>> ways:
>>>
>>> // affects state (year/month/day)
>>> date = date.withYear(2012)
>>> date = date.plusYears(6)
>>> // aftect multiple pieces of state, so past participle
>>> period = period.multipliedBy(6)
>>> period = period.negated()
>>>
>>> This is simply an extension of when you might use setXxx() on a bean,
>>> and when you might use a named method.
>>>
>>
>> I like the idea of two classes: CVSFormat and CVSFormatBuilder but...
>>
>> My next question is: Does CVSFormat have any public constructors? If not,
>> the builder can throw exceptions when one of its methods is called and
>> validation fails. This is nice in the sense that the format object feels
>> more lightweight and has a simpler/shorter protocol. It also leaves room
>> for other builders to be added (to configured formats from config files for
>> example) without growing the format class itself.
>>
>> If CVSFormat does have public constructors, then the format class still has
>> to do its own validation. What I gain is the choice of using a kitchen sink
>> constructor or the fluent builder API, I can choose my style.
>>
>> If there are two classes, and I cannot build a format without a format
>> builder, then why not collapse the two classes into one?
>>
>
> Hi Gary,
>
> I agree. I'd favor to have no public constructors and a builder that
> is an internal class of CSVFormat. Users create CSVFormatBuilders by
> calling a static method on CSVFormat:
>
> CSVFormat format =
> CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build();
>
> Where defaults() returns a builder that is initialized with (suprise)
> the values of the default format. No need to call a validate method.
If you mean that the build method does the validation, then I agree.
I think validation is necessary to check that the defined
meta-characters are distinct.
We could ignore validation and let the user define
escape=delimiter=quote , but I suspect that would generate a lot of
unnecessary user queries when things then go wrong in odd ways.
> Benedikt
>
>> Gary
>>
>>
>>> Stephen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
