On 16 March 2012 14:53, Matt Benson <gudnabr...@gmail.com> wrote: > 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.
My proposed builder does not change the current code at all. However ideally it should be defined in the same class so as to keep the constructor private (and it will need access to a private constant). Note that the original methods are also fluent in the sense that they can be chained together. The only difference is that the proposed fluent interface requires a starting method (or it could be a ctor) and a build() method call at the end. If required, both sets of methods could be maintained going forward, but that seems like an unnecessary maintenance overhead. CSV has yet to be released, so there's no need for backwards compatibilty and therefore we don't _need_ to keep the existing methods. > Matt > > On Fri, Mar 16, 2012 at 7:34 AM, James Carman > <jcar...@carmanconsulting.com> wrote: >> +1 for builder pattern and fluent API >> On Mar 16, 2012 4:24 AM, "Benedikt Ritter" <benerit...@googlemail.com> >> wrote: >> >>> Am 15. März 2012 21:20 schrieb Emmanuel Bourg <ebo...@apache.org>: >>> > Le 15/03/2012 20:26, Benedikt Ritter a écrit : >>> > >>> > >>> >> 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-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
