On Sat, Aug 3, 2013 at 12:10 PM, 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. There's no user manual or FAQ, the Javadoc is thin. How do you get started? 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 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 > > -- 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
