2013/5/21 Romain Manni-Bucau <[email protected]> > The CSVConfig solution is better IMO. > > The issue with static imports is only an issue if the api is not fluent > (delimiter, comment ...). If after one or two static imports (without * ;) > you get what i called a real builder (a fluent api) it is far easier to > enter the api. >
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. Benedikt > > JUnit is different cause you dont configure/build sthg, you just call sthg > line by line. > Le 21 mai 2013 00:42, "sebb" <[email protected]> a écrit : > > > On 20 May 2013 21:07, Romain Manni-Bucau <[email protected]> wrote: > > > Hi > > > > > > A real inline builder (withDelimiter(...)...) is better to get > completion > > > and linear reading of the code IMO > > > > What do you mean exactly by a real builder? > > Please show the exact syntax. > > > > > Static imports are not fine for everbody from my experience > > > > Nothing is going to be fine for everybody. > > But static imports seem to work quite well for JUnit4. > > > > > Le 20 mai 2013 22:05, "Benedikt Ritter" <[email protected]> a écrit : > > > > > >> Hi guys, > > >> > > >> a while back we had this discussion [1] about the current state of the > > >> CSVFormat API. We were still not completely happy with it and Oliver > > came > > >> up with a new suggestion [2]. > > >> This weekend I finally had some time to hack something together. I've > > >> created a mirror of CSV rev. 1484347 at github [3]. > > >> > > >> This proposal uses CSVFormatModifier objects to change a CSVFormat. > The > > API > > >> relies on static imports of factory methods for CSVFormatModifiers and > > >> looks like the following: > > >> > > >> CSVFormat modifed = CSVFormat.DEFAULT.with( > > > > I don't like the DEFAULT; seems to me it could be dropped. > > > > >> delimiter(';'), > > >> noEscape(), > > >> commentStart('#')); > > > > Also, I think one could chain the method parameters like so: > > > > CSVFormat modifed = > > CSVFormat.using(CSVConfig.delimiter(',').noEscape().quote('"')); > > > > I think this would eliminate the need for static imports. > > > > >> So far I've implemented methods for changing delimiter, commentStart, > > >> escape and quote policy (have a look at CSVFormatModifierTest). The > > >> approach has the advantage of being short like the initial > > implementation, > > >> while making sure that CSVFormat is immutable and validated at > > construction > > >> time. The draw back however is, that it is a bit of a pain to get all > > the > > >> static imports in place (at least this is my feeling with Eclipse, any > > >> suggestions on how to work efficiently with static imports in eclipse > > are > > >> appreciated :) > > >> > > >> Now I'd like to ask you for feedback. Do you like this approach? Any > > >> suggestions? > > >> One thing I'm not sure about is MutableCSVFormat. Maybe this can be > > merged > > >> together with CSVFormatModifier. > > >> > > >> Regards, > > >> Benedikt > > >> > > >> > > >> [1] http://markmail.org/thread/o3s2a5hyj6xh4nzj > > >> [2] http://markmail.org/message/vjjdbckwr4dlqp2b > > >> [3] https://github.com/britter/apache-commons-csv-mirror > > >> > > >> > > >> -- > > >> http://people.apache.org/~britter/ > > >> http://www.systemoutprintln.de/ > > >> http://twitter.com/BenediktRitter > > >> http://github.com/britter > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
