Gary Gregory wrote: > On Tue, Oct 16, 2012 at 9:14 AM, Jörg Schaible > <joerg.schai...@scalaris.com>wrote: > >> Hi Gary, >> >> Gary Gregory wrote: >> >> > Hi All: >> > >> > The format object can configure various aspects of input and output >> > formatting. >> > >> > With my recent addition of the Quote enum for [CSV-53], there are now >> > two aspects of quoting to configure: the quote character and the quote >> > policy (minimal, all, non-numeric, and none.) FYI, 'none' is currently >> > not implemented. >> > >> > First, I changed (without consulting this list, and please accept my >> > apologies for this) the - IMO - cryptic and burdensome terminology of >> > "encapsulator" to "quote char", and added "quote policy": >> > >> > - withQuoteChar(char) >> > - withQuotePolicy(Quote) >> > >> > My intention here is that all Quote APIs start with "withQuote" >> > followed by what aspect of quoting is being configured. >> > >> > Alternatively, we could have: >> > >> > - withQuote(char) >> > - withQuotePolicy(Quote) >> >> or >> >> - withQuote(char) >> - withQuote(Quote) >> >> ;-) >> > > Darn, I wish I knew you better to know if you were joking! :) > > This would not be good IMO because you are configuring two different > aspects of the behavior. When I see the same API name with different > parameters, I think that they are the same and that the API just does > conversions. > > We could consider making Quote a class instead of an enum and have it > carry a char and an enum, such that one object defines all quoting > aspects. This might be too normalized a design for something so simple > though.
Actually I did not had a closer look to the API. You're definitely right to use different names for different aspects. It does not make sense to overload just for fun. > > >> >> > Which makes the API more consistent with the other char/Character based >> > properties: >> > >> > - withEscape >> > - withDelimiter >> > - withLineSeparator >> > - withCommentStart >> > >> > none of the above are post-fixed with a "Char" in the name. >> > >> > As far as reading, for me, the "-r" names are OK because the they are >> > nouns (things): "a delimiter", "a line separator." But I do not talk >> about >> > "an escape" because that would be an act (think Alcatraz) as opposed to >> > what we have here: a character used to /perform/ escapes. >> > >> > So I propose to change "escape" to "escape char" because "escaper" is >> > not a word. >> > >> > The name "comment start" is not great also because it implies (to me) >> that >> > there is a "comment end" missing. So plain "comment" or "comment char" >> > would be better. >> >> Who said it has to be a single char? >> > > The current implementation does. ;) > > Are comments even in any RFC? Not that I am aware of. >> .withEOLComment("//") >> >> >> Same applies to the line separator: >> >> .withLineSeparator("\n\r") >> >> > Circling back to "quote char" which I have the way it is now for the >> > same reason as for the "escape" property. >> > >> > In summary, using *Char names is better IMO. >> >> Only if it can be a single char only. If it can either be a single char >> or a >> String, I normally tend to use overloaded methods: >> >> - withEOLComment(char) >> - withEOLComment(CharSequence) >> > > If you want to add // to the mix, please start a different thread. I'm not > sure this is really needed. Do you have a real life use case? People come up with all kind of "solutions" they are used to. CSV is brittle anyway, just because there is no "real" standard. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org