On Tue, May 21, 2013 at 11:47 AM, Benedikt Ritter <[email protected]>wrote:
> 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. > The only thing I use static imports are math-type constants. I find them misleading and non-OO for methods because I have NO IDEA what object I am sending a message to. Gary > > 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 > -- 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
