I've removed the primitive APIs from trunk. This is seems too disruptive
toward a 1.0 at this point.
Gary
On Mon, Aug 5, 2013 at 1:18 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
> It might be best to suggest a facade that handles missing converters, null
> or empty CSV fields, etc. That's why I suggested leaving the type
> conversion to the applications programmer - we can't know what the
> developer wants to do in those cases.
>
>
> -Adrian
>
>
>
> On 8/4/2013 6:53 PM, Gary Gregory wrote:
>
>> 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.crum@sandglass-**software.com<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-**softwa**re.com <http://software.com> <
>>>>>>>
>>>>>> 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-**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
>>>>
>>>>
>>
>>
>
> ------------------------------**------------------------------**---------
> 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
