On 16 October 2012 21:56, Benedikt Ritter <[email protected]> wrote: > 2012/10/16 Gary Gregory <[email protected]>: >> On Tue, Oct 16, 2012 at 1:00 PM, Stephen Colebourne >> <[email protected]>wrote: >> >>> On 16 October 2012 17:44, Matt Benson <[email protected]> wrote: >>> > On Tue, Oct 16, 2012 at 11:42 AM, James Carman >>> > <[email protected]> wrote: >>> >> On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson <[email protected]> >>> 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 >>> >>> 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. >>> >> >> I like the idea of two classes: CVSFormat and CVSFormatBuilder but... >> >> My next question is: Does CVSFormat have any public constructors? If not, >> the builder can throw exceptions when one of its methods is called and >> validation fails. This is nice in the sense that the format object feels >> more lightweight and has a simpler/shorter protocol. It also leaves room >> for other builders to be added (to configured formats from config files for >> example) without growing the format class itself. >> >> If CVSFormat does have public constructors, then the format class still has >> to do its own validation. What I gain is the choice of using a kitchen sink >> constructor or the fluent builder API, I can choose my style. >> >> If there are two classes, and I cannot build a format without a format >> builder, then why not collapse the two classes into one? >> > > Hi Gary, > > I agree. I'd favor to have no public constructors and a builder that > is an internal class of CSVFormat. Users create CSVFormatBuilders by > calling a static method on CSVFormat: > > CSVFormat format = > CSVFormat.defaults().withDelimiter('#').withCommentStart('/').build(); > > Where defaults() returns a builder that is initialized with (suprise) > the values of the default format. No need to call a validate method.
If you mean that the build method does the validation, then I agree. I think validation is necessary to check that the defined meta-characters are distinct. We could ignore validation and let the user define escape=delimiter=quote , but I suspect that would generate a lot of unnecessary user queries when things then go wrong in odd ways. > Benedikt > >> Gary >> >> >>> Stephen >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
