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
