Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 209.85.161.171 as permitted sender)
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
In-Reply-To: 
 <CALznzY7Z8DgEgMSzNPkiUHCfD0t2mfdwT9zOyx-oPCBpw9Yaig@mail.gmail.com>
References: 
 <CAB917RLD5yS-UMtXhNKRER2Qf0ZDQrUE=8Z=m3hUKeK93HTKjg@mail.gmail.com>
	<4F61077E.3010003@apache.org>
	<CAOGo0VZ4uLRFnChQh4c8S2h3y3C1J_XHf-ZmEGkmpJn7JSn=9A@mail.gmail.com>
	<CAB917RKXMfVvp94SuGMCXBn225w-0CXs0uGm=Fgz-rQyrNQ8PQ@mail.gmail.com>
	<4F610E94.4060609@apache.org>
	<CAB917RKVK9HQEYvZpmUXYQhUh1hq4zXUH6b9D4eaYBjOn9ifFw@mail.gmail.com>
	<CAOGo0VbJhMMGvfs1qDndCEg9jWZiAQ5hPJ2w6dmTVuUNo=Xjow@mail.gmail.com>
	<CAB917RK_OJs1+s40qezhZxNFXNi7C5UVX2=UX7o2eov3d=0HUA@mail.gmail.com>
	<4F624F10.3070406@apache.org>
	<CAB917RJGDTecDS6=QTB5CQixHme73yYGX4PZDmgbE=AQJhf7nQ@mail.gmail.com>
	<CALznzY7Z8DgEgMSzNPkiUHCfD0t2mfdwT9zOyx-oPCBpw9Yaig@mail.gmail.com>
Date: Fri, 16 Mar 2012 09:53:29 -0500
Message-ID: 
 <CAE9L6G03p4CjpiJFY1GAK07ZRKEVPMzYbzb=PLMZMGANB42gAQ@mail.gmail.com>
Subject: Re: [csv] Why does CSVFormat provide a validate() method instead of
 validating parameters passed to its constructor?
From: Matt Benson <gudnabrsam@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The votes show that several of us in the Commons community are leaning
more and more toward fluent APIs these days.  But rather than wasting
time going back and forth arguing about it, why not build the fluent
API separately from the rest of the package and leave the choice up to
the user?  I don't think I'm incorrect to say that this is more or
less what [digester]3 does.

Matt

On Fri, Mar 16, 2012 at 7:34 AM, James Carman
<jcarman@carmanconsulting.com> wrote:
> +1 for builder pattern and fluent API
> On Mar 16, 2012 4:24 AM, "Benedikt Ritter" <beneritter@googlemail.com>
> wrote:
>
>> Am 15. M=E4rz 2012 21:20 schrieb Emmanuel Bourg <ebourg@apache.org>:
>> > Le 15/03/2012 20:26, Benedikt Ritter a =E9crit :
>> >
>> >
>> >> How about you Emmanuel? Could sebb convince you? ;-) How about this:
>> >> I'll create a patch and attach it to JIRA. Then we'll have a better
>> >> basis for discussion.
>> >
>> >
>> > Sorry but I'm not convinced. I see exactly where this leads.
>> >
>>
>> Hey Emmanuel,
>>
>> I accept that, and I respect your decision. I don't want to argue with
>> you on this, I just want to understand your decision. From Effective
>> Java, I learned "if you are facing a constructor with lots of optional
>> arguments, consider using the builder pattern". Can you explain, why
>> you think it is not appropriate in this case? You said it is too
>> verbose, but it's just one additional call, compared with what we have
>> now.
>>
>> The advantage of the builder (sorry now I'm arguing :) is, that nobody
>> has to remember to validate the format. Even if validation is
>> something that is package private, that could lead to the point where
>> someone forgets to add that line. Now you could say we have unit tests
>> for that. But isn't it the responsibility of an object to verify that
>> it is being instantiated into a valid state?
>> Also we don't know yet, if there always will be only one package in
>> the library. What if, we add another package (o.a.c.csv.beanmapping or
>> what ever) and we want to use CSVFormat there. Then we would have to
>> make validate public, exposing it to the outside world.
>>
>> > If you have some free time and want to do something fun you can try
>> > reimplementing the parser with less array copies. Commons CSV is still
>> > behind the other APIs on the performance side.
>> >
>>
>> I'll have a look at that, and at what Ted suggested on the other thread.
>>
>> TIA for taking your time to explain!!
>> Benedikt
>>
>> > Emmanuel Bourg
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org