Thank you for pointing this, I didn't notice this recent addition. I'm not fond of the parseType(Type t) methods, I'd prefer parse(Type t).
Btw I would have kept these methods out of csv 1.0, this is again delaying the release with another discussion... Emmanuel Bourg Le 08/08/2013 10:24, Benedikt Ritter a écrit : > Hi, > > we currently have several static factory methods in CSVParser: > > - public static CSVParser parseFile(File file, final CSVFormat format) > throws IOException > - public static CSVParser parseResource(String resource, Charset charset, > ClassLoader classLoader, > final CSVFormat format) throws IOException > - public static CSVParser parseResource(String resource, Charset charset, > final CSVFormat format) throws IOException > - public static CSVParser parseString(String string) throws IOException > - public static CSVParser parseString(String string, final CSVFormat > format) throws IOException > - public static CSVParser parseURL(URL url, Charset charset, final > CSVFormat format) throws IOException > > and one instance factory method in CSVFormat: > > - public CSVParser parse(final Reader in) throws IOException > > One can also create a parser using the public constructors defined in > CSVParser: > > - public CSVParser(final Reader input) throws IOException > - public CSVParser(final Reader reader, final CSVFormat format) throws > IOException > > I'm wondering: > > 1. do we need all this different ways to create CSVParsers? For example it > may be confusing to have parse(Reader) in CSVFormat which is pretty much > the same as CSVParser(Reader, CSVFormat) just the other way around. > > 2. all the factory methods are named "parseXXX" but they don't actually > parse anything. They just create an object that is capable of parsing CSV > content. Should the factory methods be renamed? > > Benedikt > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
