2012/10/16 Stephen Colebourne <scolebou...@joda.org>: > On 16 October 2012 17:44, Matt Benson <gudnabr...@gmail.com> wrote: >> On Tue, Oct 16, 2012 at 11:42 AM, James Carman >> <ja...@carmanconsulting.com> wrote: >>> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>>> >>>> Are these specific examples not the words you would actually use were >>>> you having a discussion on the subject in English? :P >>>> >>> >>> Why not just support both? The "with*" methods would just be aliases >>> for the more "natural language" method names. > > I would categorise first in two > - mutable builders producing immutable objects > - immutable objects >
Implementing a builder for CSVFormat was discussed a while ago [1]. I think it's the best solution, because the validate method can then made private and no code outside the format has to worry about whether a format is valid or not (right now CSV code calls validate on newly created CSVFormat instances to make sure they are valid.). Anyway there were voices against a builder because it would complicate the API, so we never implemented something like that... Benedikt [1] http://markmail.org/thread/mmeoymd3cpq5jxfr > The former should generally have short methods without prefixes, the > latter is more complex. > > For the latter, as a general rule, I use > withXxx()/plusXxx()/minusXxx() for items that affect the state and > past participle for other methods that manipulate the object in other > ways: > > // affects state (year/month/day) > date = date.withYear(2012) > date = date.plusYears(6) > // aftect multiple pieces of state, so past participle > period = period.multipliedBy(6) > period = period.negated() > > This is simply an extension of when you might use setXxx() on a bean, > and when you might use a named method. > > Stephen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
