Maybe we first have to decide if we want validation of CSVFormats at construction time or not. If not, the changes of CSV-68 can be reverted.
Benedikt 2012/11/21 James Carman <ja...@carmanconsulting.com> > I don't really have a problem with the extra call to build() before > you have something useful. It does give us the ability to do > validation on the object before you build it. If we choose not to do > the validation at this time, that's fine, but if we ever do choose to > add that in the future, we don't have to break API backward > compatibility to do so. > > On Tue, Nov 20, 2012 at 5:57 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > Ok this is good. Let's see some healthy debating. :) > > > > What is the alternate API? > > > > To me the bother is the extra build() call, but that's the pattern. > > > > Could an alt API be used and co-exist? > > > > Is making the ctor an option? It would have to do some validation. > > > > Gary > > > > On Nov 20, 2012, at 16:59, Emmanuel Bourg <ebo...@apache.org> wrote: > > > >> Le 20/11/2012 20:01, Benedikt Ritter a écrit : > >> > >>> Please share your thoughts about the builder. > >> > >> Sorry Benedikt but I have to say I really don't like this design. I > >> prefer a simpler API for the reasons you mentioned in the disadvantages. > >> The minor improvements from the developer's point of view are much less > >> important than the ease of use from user's point of view. > >> > >> Emmanuel Bourg > >> > >> > > > > --------------------------------------------------------------------- > > 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 > >
