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
