Adrian, the conversions would be configurable. At least that's how I envisioned it using existing BeanUtils functionality. Gary has a request our to me to demo that. On Aug 3, 2013 11:10 AM, "Adrian Crum" <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-**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. 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? > > > >> 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 access or convert >>>> typed >>>> values. We could: >>>> >>>> - Document the new APIs, or remove them AND: >>>> - Document how to use another Commons API >>>> - Document how to use another (non Commons) API >>>> - Document how to do it all yourself >>>> - Create a CSVRecrord wrapper class that contains all the APIs where the >>>> implementation may or may not delegate to another Commons API. >>>> >>>> No matter what, it's pretty obvious that this conversion code is going >>>> to >>>> exist somewhere, in the user's app, in [csv] or someplace else. >>>> >>>> We should make a plan such that if we do not provide this feature in >>>> 1.0, >>>> we have a roadmap for our users. >>>> >>>> Gary >>>> >>>> >>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apac**he.org<http://apache.org> >>> <dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>> > >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
