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.
>
> > 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?
>
> .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?
Merci!
Gary
>
> > Discuss! :)
>
> Can or worms opened :))
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
