Am 06.06.2013 um 18:21 schrieb Gary Gregory <[email protected]>:
> On Wed, Jun 5, 2013 at 9:22 AM, Benedikt Ritter <[email protected]> wrote: > >> 2013/5/23 Gary Gregory <[email protected]> >> >>> On Thu, May 23, 2013 at 3:31 AM, Benedikt Ritter <[email protected]> >>> wrote: >>> >>>> 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 not sure which is which anymore and I do not want to take the time >>> today to dive back in this one. But it does feel we are getting close... >> to >>> something ;) >>> >> >> >> Sorry, for the late follow up... >> What we are talking about is probably something like r1399051 [1] but with >> a public ctor. >> >> WDYT? >> > > That should be OK. Turning the default ctor into a public one should > satisfy both audiences: the fluent-obsessed and the I-know-what-I'm-doing. I have created CSV-99 [1] to keep track of this change. Benedikt [1] https://issues.apache.org/jira/browse/CSV-99 > > Gary > > >> >> Benedikt >> >> [1] >> >> http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java?revision=1399051&view=markup >> >> >>> >>> Gary >>> >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
