On Sat, Aug 3, 2013 at 1:31 PM, James Carman <ja...@carmanconsulting.com>wrote:
> +1. We need to eat our own dog food when it makes sense. Would this be the proper way to do things with [convert]? import org.apache.commons.convert.ConversionException; import org.apache.commons.convert.Converters; public class CSVRecordConverter { public CSVRecordConverter(CSVRecord record) { super(); this.record = record; } private final CSVRecord record; public boolean getBoolean(String name) throws ClassNotFoundException, ConversionException { return Converters.getConverter(String.class, Boolean.class).convert(record.get(name)).booleanValue(); } } ClassNotFoundException seems really out of place here. I read "If no matching Converter is found, the method throws ClassNotFoundException." It seems to me that a ConversionException would be better. ? Gary > Our package > rename approach helps solve the "jar hell" issue, so adding dependencies > shouldn't be so frowned upon. Obviously if it's one little helper method > here and there we can copy the code if folks are really that averse to > dependencies. > > > On Saturday, August 3, 2013, Paul Benedict wrote: > > > If Convert and BeanUtils do the same thing, I think Commons needs to > figure > > out how to solve this dilemma because duplicated functionality is usually > > frowned upon here. For example, when Commons Lang began doing math, they > > moved that to Commons Math (and the same thing happened for BeanUtils > from > > Lang). > > > > If Convert is to be released, I think BeanUtils should get some > refactoring > > for a 2.0 release. They should harmonize but not duplicate functionality. > > > > Paul > > > > > > On Sat, Aug 3, 2013 at 11:58 AM, Gary Gregory <garydgreg...@gmail.com > <javascript:;> > > >wrote: > > > > > On Sat, Aug 3, 2013 at 12:55 PM, Adrian Crum < > > > adrian.c...@sandglass-software.com> wrote: > > > > > > > On 8/3/2013 9:49 AM, Gary Gregory wrote: > > > > > > > >> On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum < > > > >> adrian.crum@sandglass-**software.com < > > > adrian.c...@sandglass-software.com>> > > > >> wrote: > > > >> > > > >> Inline... > > > >>> > > > >>> > > > >>> On 8/3/2013 9:05 AM, Gary Gregory wrote: > > > >>> > > > >>> On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum < > > > >>>> adrian.crum@sandglass-**softwa**re.com <http://software.com> < > > > >>>> adrian.crum@sandglass-**software.com< > > > adrian.c...@sandglass-software.com> > > > >>>> >> > > > >>>> > > > >>>> wrote: > > > >>>> > > > >>>> Have you considered recommending Commons Convert? > > > >>>> > > > >>>>> No: it is unreleased. Are you willing to help polish it to 1.0? > > > >>>>> > > > >>>> Aside from a pending bug fix, the code is complete. The project > has > > > been > > > >>> used by Apache OFBiz for years, so it is proven and stable. So, I > > don't > > > >>> know what additional steps are required to polish it. > > > >>> > > > >> > > > >> There's no user manual or FAQ, the Javadoc is thin. How do you get > > > >> started? > > > >> > > > > > > > > > > > > I will try to build out the docs a little more. I think I need karma > to > > > > edit the Convert Wiki - adrianc. > > > > > > > > > > The docs should be in SVN IMO, just like most components. > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > >> More below. > > > >> > > > >> > > > >> Having an official release would be wonderful. > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> Yes: I'd like to eat our own dog food. > > > >>>> > > > >>>> Gary > > > >>>> > > > >>>> I agree that Java data type conversion is outside the scope of > > CSV. > > > >>>> > > > >>>>> What about a CSVRecord wrapper that delegates to [convert]? > > > >>>>> > > > >>>> What would that look like? From my experience, hard-coding > > conversions > > > >>> is > > > >>> not scalable. If an application needs to convert a CSV field to a > > > custom > > > >>> type Foo, how will the wrapper accommodate that? > > > >>> > > > >>> It would not for now. This is just about primitives or basic JRE > > types > > > >> like > > > >> Number and Date (Calendar). > > > >> > > > >> Gary > > > >> > > > >> > > > >> > > > >>> > > > >>> Gary > > > >>>> > > > >>>> > > > >>>> -Adrian > > > >>>> > > > >>>>> > > > >>>>> On 8/3/2013 8:36 AM, Gary Gregory wrote: > > > >>>>> > > > >>>>> Hi All: > > > >>>>> > > > >>>>>> I recently added these CSVRecord APIs: getBoolean(String), > > > >>>>>> getInt(String), > > > >>>>>> getLong(String), getBigInteger(String). > > > >>>>>> > > > >>>>>> Some people are OK with this, some consider this out of scope, > > some > > > >>>>>> consider it not necessary for 1.0, some -1, some are worried > about > > > >>>>>> feature > > > >>>>>> creep (default values, Calendar, Date, List, and so on), some > > think > > > >>>>>> the > > > >>>>>> Javadoc should be clearer. > > > >>>>>> > > > >>>>>> At the very least I think we should document how to -- > > Cheers, > > Paul > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory