2013/5/21 Gary Gregory <[email protected]> > On Tue, May 21, 2013 at 2:52 PM, Benedikt Ritter <[email protected]> > wrote: > > > 2013/5/21 Emmanuel Bourg <[email protected]> > > > > > Le 21/05/2013 17:47, Benedikt Ritter a écrit : > > > > > > > Well that still doesn't tell us, what your definition of a "real" > > builder > > > > is :-) The latest trunk contains a builder implementation with a > fluent > > > > API. It has been criticized for being to verbose when creating new > > > formats > > > > from existing ones. This is why we came up with this new proposal, > that > > > is > > > > less verbose but requires static imports. > > > > > > What about simply going back to the previous design (fluent API without > > > builder) ? The only drawback was the need to validate the format > > > explicitly. That is the best compromise IMHO. > > > > > > > Hi Emmanuel, > > > > I think we have discussed this a lot (maybe to much). You certainly know > my > > arguments against the old solution and I still think they are valid. > Also, > > I understand your arguments and think they are equally valid. > > I believe we have tried a lot to finally reach consensus about this > issue. > > We have tried several solutions and to me it seems, that consensus can > > simply not be reached (an argument that can't be settled in 5 minutes > can't > > be settled with arguments at all). > > > > Having this said, I'm willing to give my +0 for going back for the old > impl > > if the others (by this I specially me Gary and sebb) also agree. > > I believe that this issue has blocked us for such a long time from > pushing > > csv forward, that it is time to overcome personal preferences and just > > chose one solution or the other. > > > > So if you can at least convince Gary and sebb, let's do it and then go > on. > > I want to see csv see the light of day :-) > > > > Nice message Benedikt. >
Thanks :) > > At the end of the day, here is what I am looking for: Don't force me to use > a style of API to use the product. If I want to use fat constructors that > may be hard to read, let me. If I want to use a fluent API, provide it and > let people who like that style use it. At a lower level, do make things > immutable where they make sense. If the fluent API and/or the immutability > of some objects has the side effect or creating a lot of garbage, then that > is the cost of using that feature, which is why I do not want to force > people to use it. Let there be light ;) > So this is your +1 for the old API + public ctor? I'm excited to hear sebb's opinion :) Benedikt > > Gary > > > > Benedikt > > > > > > > > > > Emmanuel Bourg > > > > > > > > > > > > > > > -- > > http://people.apache.org/~britter/ > > http://www.systemoutprintln.de/ > > http://twitter.com/BenediktRitter > > http://github.com/britter > > > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition< > http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
