2012/10/17 sebb <seb...@gmail.com>:
> 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.
yep, the build should take care of the validation.
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
