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