Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.3 as permitted sender)
To: dev@commons.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible <Joerg.Schaible@scalaris.com>
Subject: Re: [csv] CSVFormat API names
Date: Tue, 16 Oct 2012 15:14:42 +0200
Organization: Scalaris AG
Lines: 83
Message-ID: <k5jmk0$c2u$1@ger.gmane.org>
References: 
 <CACZkXPy=Ob7xUMbe8N3iA9s4e73b-TokR5pzCuhAnuaJ+b_rBQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/4.8.5

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)

;-)

> 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?

.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)

> Discuss! :)

Can or worms opened :))

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org