commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: [csv] accessing primitives and other record values
Date Sat, 03 Aug 2013 16:55:16 GMT
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> 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.crum@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.


>
> 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-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message