You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2013/08/01 16:00:23 UTC
[csv] record.get APIs for primitive types
I would like to note this CSVRecord addition I am planning on:
public Boolean getBoolean(String name) {
public boolean getBooleanPrimitive(String name)
The method listings are at the end of this message.
What I want to note here is that these are conversion methods and that the
record still stores the values internally as Strings. I do not want to
Javadoc the conversion in order to give us flexibility over representation
if we decide to change it in the future (caching or whatnot).
I wanted to post here in CTR mode before I or others add APIs like
getLong() and getLongPrimitive(). Since this is a library, I do believe we
should end up providing such APIs at the record level for primitives.
/**
* Returns a value by name.
*
* @param name
* the name of the column to be retrieved.
* @return the column value, or {@code null} if the column name is not
found
* @throws IllegalStateException
* if no header mapping was provided
* @throws IllegalArgumentException
* if the record is inconsistent
* @see #isConsistent()
*/
public Boolean getBoolean(String name) {
String s = this.get(name);
return s != null ? Boolean.valueOf(s) : null;
}
/**
* Returns a value by name.
*
* @param name
* the name of the column to be retrieved.
* @return the column value, or {@code false} if the column name is not
found
* @throws IllegalStateException
* if no header mapping was provided
* @throws IllegalArgumentException
* if the record is inconsistent
* @see #isConsistent()
*/
public boolean getBooleanPrimitive(String name) {
return Boolean.parseBoolean(this.get(name));
}
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [csv] record.get APIs for primitive types
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Aug 1, 2013 at 3:45 PM, Benedikt Ritter <br...@apache.org> wrote:
> I agree with Gary. This sounds like a useful feature that doesn't seem to
> be to hard to implement. And if he (Gary) has the time to do the necessary
> coding, why not?
>
> The only thing I don't like is the getBooleanPrimitive(String) method. I
> think it is enough to have a getBoolean(String) that returns a boolean. If
> users need a Boolean, they can create one or make use of auto boxing.
>
In the current scheme, the reason you need getBoolean() to return a Boolean
is that you can get a null if the column is not mapped, just like with
get(String) today. The semantics have to match IMO.
If getBoolean() returns a boolean, then you get a false if the column is
not mapped, so you cannot tell a real 'false' from a missing column.
The alternative is to have one API, like you suggest, and have it throw an
exception if the column is not mapped. We'd have to change get() to match.
I think that would be OK.
All get() methods either return a real value or throw an exception, they
would not return null if a column is not mapped.
To summarize, either
(1) have both 'Boolean getBoolean(String)' and 'boolean
getBooleanPrimitive(String)', or
(2) have one 'boolean getBoolean(String)' that throws an IAE if the column
is not mapped.
I am leaning towards 2. Error checking can be done with isMapped(String)
for those who need it.
Gary
>
> And what about the get(int) and get(Enum) methods? Do we want converter
> pendants for these?
>
> Benedikt
>
>
> 2013/8/1 Gary Gregory <ga...@gmail.com>
>
> > On Thu, Aug 1, 2013 at 10:30 AM, sebb <se...@gmail.com> wrote:
> >
> > > On 1 August 2013 15:21, Emmanuel Bourg <eb...@apache.org> wrote:
> > > > Just like the bean mapping I prefer to keep the type conversion out
> of
> > > 1.0.
> > > >
> > >
> > > +1
> > >
> > > It's definitely not essential to the initial release.
> > >
> >
> > It's one of those things that was not essential to me until I had a use
> > case for it! :) I could create a wrapper class forCSVRecord too, but
> that's
> > not as nice.
> >
> > In any case, I look at this as something I can put in, understanding that
> > some others are not interested in doing it now. This should not hold up
> the
> > release, and I do not think it is.
> >
> >
> > > I'm not sure it belongs in CSV at all.
> > >
> >
> > I disagree with that statement. When you look at the JDBC ResultSet API,
> > these kinds of methods are there, and it feels right to have these kinds
> of
> > methods in here too.
> >
> > Granted we are not building a JDBC driver, but this kind of functionality
> > feels pretty basic, unlike mapping to model beans, which is a good
> feature,
> > but feels more advanced and creeps into more JPA-like scenarios.
> >
> > Gary
> >
> >
> > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > > Le 01/08/2013 16:00, Gary Gregory a écrit :
> > > >> I would like to note this CSVRecord addition I am planning on:
> > > >>
> > > >> public Boolean getBoolean(String name) {
> > > >> public boolean getBooleanPrimitive(String name)
> > > >>
> > > >> The method listings are at the end of this message.
> > > >>
> > > >> What I want to note here is that these are conversion methods and
> that
> > > the
> > > >> record still stores the values internally as Strings. I do not want
> to
> > > >> Javadoc the conversion in order to give us flexibility over
> > > representation
> > > >> if we decide to change it in the future (caching or whatnot).
> > > >>
> > > >> I wanted to post here in CTR mode before I or others add APIs like
> > > >> getLong() and getLongPrimitive(). Since this is a library, I do
> > believe
> > > we
> > > >> should end up providing such APIs at the record level for
> primitives.
> > > >>
> > > >> /**
> > > >> * Returns a value by name.
> > > >> *
> > > >> * @param name
> > > >> * the name of the column to be retrieved.
> > > >> * @return the column value, or {@code null} if the column name
> is
> > > not
> > > >> found
> > > >> * @throws IllegalStateException
> > > >> * if no header mapping was provided
> > > >> * @throws IllegalArgumentException
> > > >> * if the record is inconsistent
> > > >> * @see #isConsistent()
> > > >> */
> > > >> public Boolean getBoolean(String name) {
> > > >> String s = this.get(name);
> > > >> return s != null ? Boolean.valueOf(s) : null;
> > > >> }
> > > >>
> > > >> /**
> > > >> * Returns a value by name.
> > > >> *
> > > >> * @param name
> > > >> * the name of the column to be retrieved.
> > > >> * @return the column value, or {@code false} if the column name
> > is
> > > not
> > > >> found
> > > >> * @throws IllegalStateException
> > > >> * if no header mapping was provided
> > > >> * @throws IllegalArgumentException
> > > >> * if the record is inconsistent
> > > >> * @see #isConsistent()
> > > >> */
> > > >> public boolean getBooleanPrimitive(String name) {
> > > >> return Boolean.parseBoolean(this.get(name));
> > > >> }
> > > >>
> > > >> Gary
> > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: 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
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [csv] record.get APIs for primitive types
Posted by sebb <se...@gmail.com>.
On 1 August 2013 23:32, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 01/08/2013 21:45, Benedikt Ritter a écrit :
>> I agree with Gary. This sounds like a useful feature that doesn't seem to
>> be to hard to implement. And if he (Gary) has the time to do the necessary
>> coding, why not?
>
> Because you start with getBoolean(), then you add getInt(), getDate(),
> getList(), methods with a default value... and you end with an insanely
> big class. We did that for [configuration] and I don't think [csv]
> should follow this path.
+1
Converting strings to primitives is out of scope for CSV.
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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
Re: [csv] record.get APIs for primitive types
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 01/08/2013 21:45, Benedikt Ritter a écrit :
> I agree with Gary. This sounds like a useful feature that doesn't seem to
> be to hard to implement. And if he (Gary) has the time to do the necessary
> coding, why not?
Because you start with getBoolean(), then you add getInt(), getDate(),
getList(), methods with a default value... and you end with an insanely
big class. We did that for [configuration] and I don't think [csv]
should follow this path.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] record.get APIs for primitive types
Posted by Benedikt Ritter <br...@apache.org>.
I agree with Gary. This sounds like a useful feature that doesn't seem to
be to hard to implement. And if he (Gary) has the time to do the necessary
coding, why not?
The only thing I don't like is the getBooleanPrimitive(String) method. I
think it is enough to have a getBoolean(String) that returns a boolean. If
users need a Boolean, they can create one or make use of auto boxing.
And what about the get(int) and get(Enum) methods? Do we want converter
pendants for these?
Benedikt
2013/8/1 Gary Gregory <ga...@gmail.com>
> On Thu, Aug 1, 2013 at 10:30 AM, sebb <se...@gmail.com> wrote:
>
> > On 1 August 2013 15:21, Emmanuel Bourg <eb...@apache.org> wrote:
> > > Just like the bean mapping I prefer to keep the type conversion out of
> > 1.0.
> > >
> >
> > +1
> >
> > It's definitely not essential to the initial release.
> >
>
> It's one of those things that was not essential to me until I had a use
> case for it! :) I could create a wrapper class forCSVRecord too, but that's
> not as nice.
>
> In any case, I look at this as something I can put in, understanding that
> some others are not interested in doing it now. This should not hold up the
> release, and I do not think it is.
>
>
> > I'm not sure it belongs in CSV at all.
> >
>
> I disagree with that statement. When you look at the JDBC ResultSet API,
> these kinds of methods are there, and it feels right to have these kinds of
> methods in here too.
>
> Granted we are not building a JDBC driver, but this kind of functionality
> feels pretty basic, unlike mapping to model beans, which is a good feature,
> but feels more advanced and creeps into more JPA-like scenarios.
>
> Gary
>
>
> >
> > > Emmanuel Bourg
> > >
> > >
> > > Le 01/08/2013 16:00, Gary Gregory a écrit :
> > >> I would like to note this CSVRecord addition I am planning on:
> > >>
> > >> public Boolean getBoolean(String name) {
> > >> public boolean getBooleanPrimitive(String name)
> > >>
> > >> The method listings are at the end of this message.
> > >>
> > >> What I want to note here is that these are conversion methods and that
> > the
> > >> record still stores the values internally as Strings. I do not want to
> > >> Javadoc the conversion in order to give us flexibility over
> > representation
> > >> if we decide to change it in the future (caching or whatnot).
> > >>
> > >> I wanted to post here in CTR mode before I or others add APIs like
> > >> getLong() and getLongPrimitive(). Since this is a library, I do
> believe
> > we
> > >> should end up providing such APIs at the record level for primitives.
> > >>
> > >> /**
> > >> * Returns a value by name.
> > >> *
> > >> * @param name
> > >> * the name of the column to be retrieved.
> > >> * @return the column value, or {@code null} if the column name is
> > not
> > >> found
> > >> * @throws IllegalStateException
> > >> * if no header mapping was provided
> > >> * @throws IllegalArgumentException
> > >> * if the record is inconsistent
> > >> * @see #isConsistent()
> > >> */
> > >> public Boolean getBoolean(String name) {
> > >> String s = this.get(name);
> > >> return s != null ? Boolean.valueOf(s) : null;
> > >> }
> > >>
> > >> /**
> > >> * Returns a value by name.
> > >> *
> > >> * @param name
> > >> * the name of the column to be retrieved.
> > >> * @return the column value, or {@code false} if the column name
> is
> > not
> > >> found
> > >> * @throws IllegalStateException
> > >> * if no header mapping was provided
> > >> * @throws IllegalArgumentException
> > >> * if the record is inconsistent
> > >> * @see #isConsistent()
> > >> */
> > >> public boolean getBooleanPrimitive(String name) {
> > >> return Boolean.parseBoolean(this.get(name));
> > >> }
> > >>
> > >> Gary
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: 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
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [csv] record.get APIs for primitive types
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Aug 1, 2013 at 10:30 AM, sebb <se...@gmail.com> wrote:
> On 1 August 2013 15:21, Emmanuel Bourg <eb...@apache.org> wrote:
> > Just like the bean mapping I prefer to keep the type conversion out of
> 1.0.
> >
>
> +1
>
> It's definitely not essential to the initial release.
>
It's one of those things that was not essential to me until I had a use
case for it! :) I could create a wrapper class forCSVRecord too, but that's
not as nice.
In any case, I look at this as something I can put in, understanding that
some others are not interested in doing it now. This should not hold up the
release, and I do not think it is.
> I'm not sure it belongs in CSV at all.
>
I disagree with that statement. When you look at the JDBC ResultSet API,
these kinds of methods are there, and it feels right to have these kinds of
methods in here too.
Granted we are not building a JDBC driver, but this kind of functionality
feels pretty basic, unlike mapping to model beans, which is a good feature,
but feels more advanced and creeps into more JPA-like scenarios.
Gary
>
> > Emmanuel Bourg
> >
> >
> > Le 01/08/2013 16:00, Gary Gregory a écrit :
> >> I would like to note this CSVRecord addition I am planning on:
> >>
> >> public Boolean getBoolean(String name) {
> >> public boolean getBooleanPrimitive(String name)
> >>
> >> The method listings are at the end of this message.
> >>
> >> What I want to note here is that these are conversion methods and that
> the
> >> record still stores the values internally as Strings. I do not want to
> >> Javadoc the conversion in order to give us flexibility over
> representation
> >> if we decide to change it in the future (caching or whatnot).
> >>
> >> I wanted to post here in CTR mode before I or others add APIs like
> >> getLong() and getLongPrimitive(). Since this is a library, I do believe
> we
> >> should end up providing such APIs at the record level for primitives.
> >>
> >> /**
> >> * Returns a value by name.
> >> *
> >> * @param name
> >> * the name of the column to be retrieved.
> >> * @return the column value, or {@code null} if the column name is
> not
> >> found
> >> * @throws IllegalStateException
> >> * if no header mapping was provided
> >> * @throws IllegalArgumentException
> >> * if the record is inconsistent
> >> * @see #isConsistent()
> >> */
> >> public Boolean getBoolean(String name) {
> >> String s = this.get(name);
> >> return s != null ? Boolean.valueOf(s) : null;
> >> }
> >>
> >> /**
> >> * Returns a value by name.
> >> *
> >> * @param name
> >> * the name of the column to be retrieved.
> >> * @return the column value, or {@code false} if the column name is
> not
> >> found
> >> * @throws IllegalStateException
> >> * if no header mapping was provided
> >> * @throws IllegalArgumentException
> >> * if the record is inconsistent
> >> * @see #isConsistent()
> >> */
> >> public boolean getBooleanPrimitive(String name) {
> >> return Boolean.parseBoolean(this.get(name));
> >> }
> >>
> >> Gary
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [csv] record.get APIs for primitive types
Posted by sebb <se...@gmail.com>.
On 1 August 2013 15:21, Emmanuel Bourg <eb...@apache.org> wrote:
> Just like the bean mapping I prefer to keep the type conversion out of 1.0.
>
+1
It's definitely not essential to the initial release.
I'm not sure it belongs in CSV at all.
> Emmanuel Bourg
>
>
> Le 01/08/2013 16:00, Gary Gregory a écrit :
>> I would like to note this CSVRecord addition I am planning on:
>>
>> public Boolean getBoolean(String name) {
>> public boolean getBooleanPrimitive(String name)
>>
>> The method listings are at the end of this message.
>>
>> What I want to note here is that these are conversion methods and that the
>> record still stores the values internally as Strings. I do not want to
>> Javadoc the conversion in order to give us flexibility over representation
>> if we decide to change it in the future (caching or whatnot).
>>
>> I wanted to post here in CTR mode before I or others add APIs like
>> getLong() and getLongPrimitive(). Since this is a library, I do believe we
>> should end up providing such APIs at the record level for primitives.
>>
>> /**
>> * Returns a value by name.
>> *
>> * @param name
>> * the name of the column to be retrieved.
>> * @return the column value, or {@code null} if the column name is not
>> found
>> * @throws IllegalStateException
>> * if no header mapping was provided
>> * @throws IllegalArgumentException
>> * if the record is inconsistent
>> * @see #isConsistent()
>> */
>> public Boolean getBoolean(String name) {
>> String s = this.get(name);
>> return s != null ? Boolean.valueOf(s) : null;
>> }
>>
>> /**
>> * Returns a value by name.
>> *
>> * @param name
>> * the name of the column to be retrieved.
>> * @return the column value, or {@code false} if the column name is not
>> found
>> * @throws IllegalStateException
>> * if no header mapping was provided
>> * @throws IllegalArgumentException
>> * if the record is inconsistent
>> * @see #isConsistent()
>> */
>> public boolean getBooleanPrimitive(String name) {
>> return Boolean.parseBoolean(this.get(name));
>> }
>>
>> Gary
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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
Re: [csv] record.get APIs for primitive types
Posted by Emmanuel Bourg <eb...@apache.org>.
Just like the bean mapping I prefer to keep the type conversion out of 1.0.
Emmanuel Bourg
Le 01/08/2013 16:00, Gary Gregory a écrit :
> I would like to note this CSVRecord addition I am planning on:
>
> public Boolean getBoolean(String name) {
> public boolean getBooleanPrimitive(String name)
>
> The method listings are at the end of this message.
>
> What I want to note here is that these are conversion methods and that the
> record still stores the values internally as Strings. I do not want to
> Javadoc the conversion in order to give us flexibility over representation
> if we decide to change it in the future (caching or whatnot).
>
> I wanted to post here in CTR mode before I or others add APIs like
> getLong() and getLongPrimitive(). Since this is a library, I do believe we
> should end up providing such APIs at the record level for primitives.
>
> /**
> * Returns a value by name.
> *
> * @param name
> * the name of the column to be retrieved.
> * @return the column value, or {@code null} if the column name is not
> found
> * @throws IllegalStateException
> * if no header mapping was provided
> * @throws IllegalArgumentException
> * if the record is inconsistent
> * @see #isConsistent()
> */
> public Boolean getBoolean(String name) {
> String s = this.get(name);
> return s != null ? Boolean.valueOf(s) : null;
> }
>
> /**
> * Returns a value by name.
> *
> * @param name
> * the name of the column to be retrieved.
> * @return the column value, or {@code false} if the column name is not
> found
> * @throws IllegalStateException
> * if no header mapping was provided
> * @throws IllegalArgumentException
> * if the record is inconsistent
> * @see #isConsistent()
> */
> public boolean getBooleanPrimitive(String name) {
> return Boolean.parseBoolean(this.get(name));
> }
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] record.get APIs for primitive types
Posted by Benedikt Ritter <br...@apache.org>.
2013/8/2 Oliver Heger <ol...@oliver-heger.de>
> Am 02.08.2013 02:34, schrieb James Carman:
> > Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
> > have the functionality, especially for Strings, and it's extensible,
> > we could recommend that in the Javadocs perhaps.
> >
> > That Converter API is screaming for some generics action!
>
> Just for the record and because [configuration] has already been
> mentioned in this thread:
>
> One of the next points on my todo list to get [configuration] 2.0 out is
> to rework the conversion framework. Currently, we have a big class doing
> all kinds of conversions. I am going to change this to have an
> extensible converter framework.
>
> I would really love to make use of [beanutils], however, as soon as some
> classes of another project become part of your public API, you are tight
> to this project. For instance, [configuration] 1.x depends on [lang]
> 2.x. After the major release of [lang] 3.0, we got many requests to
> update the dependency, but this was not possible in a minor release due
> to binary incompatible changes - because of the changed package
> structure in [lang] the API of [configuration] would also change.
>
OT:
Just for the record: I'd not recommend using beanutils 1.x in any
component.
I've worked on the 1.x version a while ago and I think it has a lot of
issues (from todays PoV).
I'm not even sure it makes sense to put the effort into 1.9.
Maybe it's better to reboot and go directly for 2.0. But that's a different
topic.
Benedikt
>
> Something similar can happen with [beanutils], too - work on version 2.0
> has already started.
>
> Oliver
>
> >
> > On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict <pb...@apache.org>
> wrote:
> >> I can see that we should provide a decorator/delegate
> (CSVRecordWrapper?)
> >> that has these additional methods and defers them to Beanutils. We
> should
> >> use our other Commons project to accomplish the pluggable and
> configurable
> >> conversion. Beanutils can be an optional Maven dependency. This doesn't
> >> belong in Commons Langs, because that's where the functionality was
> before
> >> migrating to its own BeanUtils project (circa 2001ish).
> >> On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
> >>
> >>> Perhaps it belongs in Commons Lang?
> >>>
> >>> Anything like this that you try to put together is going to blow up
> >>> really quickly, by the way (registering new converter types, etc.). I
> >>> don't see how having a few little helper methods in CSV is that big of
> >>> an issue, personally.
> >>>
> >>> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
> >>> <pa...@gmail.com> wrote:
> >>>> You might want to think of a conversion addon package using Common
> >>>> BeanUtils. That project is skilled at conversions from String and has
> >>>> pluggable capability to customize conversion types.
> >>>> On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
> >>>>
> >>>>> None of these methods document exceptions if the conversion fails
> (eg,
> >>> not
> >>>>> an integer). Also, how strict is the conversion? Can "x" represent
> >>> boolean
> >>>>> false or is that an exception?
> >>>>> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com>
> wrote:
> >>>>>
> >>>>>> I would like to note this CSVRecord addition I am planning on:
> >>>>>>
> >>>>>> public Boolean getBoolean(String name) {
> >>>>>> public boolean getBooleanPrimitive(String name)
> >>>>>>
> >>>>>> The method listings are at the end of this message.
> >>>>>>
> >>>>>> What I want to note here is that these are conversion methods and
> that
> >>> the
> >>>>>> record still stores the values internally as Strings. I do not want
> to
> >>>>>> Javadoc the conversion in order to give us flexibility over
> >>> representation
> >>>>>> if we decide to change it in the future (caching or whatnot).
> >>>>>>
> >>>>>> I wanted to post here in CTR mode before I or others add APIs like
> >>>>>> getLong() and getLongPrimitive(). Since this is a library, I do
> >>> believe we
> >>>>>> should end up providing such APIs at the record level for
> primitives.
> >>>>>>
> >>>>>> /**
> >>>>>> * Returns a value by name.
> >>>>>> *
> >>>>>> * @param name
> >>>>>> * the name of the column to be retrieved.
> >>>>>> * @return the column value, or {@code null} if the column name
> is
> >>> not
> >>>>>> found
> >>>>>> * @throws IllegalStateException
> >>>>>> * if no header mapping was provided
> >>>>>> * @throws IllegalArgumentException
> >>>>>> * if the record is inconsistent
> >>>>>> * @see #isConsistent()
> >>>>>> */
> >>>>>> public Boolean getBoolean(String name) {
> >>>>>> String s = this.get(name);
> >>>>>> return s != null ? Boolean.valueOf(s) : null;
> >>>>>> }
> >>>>>>
> >>>>>> /**
> >>>>>> * Returns a value by name.
> >>>>>> *
> >>>>>> * @param name
> >>>>>> * the name of the column to be retrieved.
> >>>>>> * @return the column value, or {@code false} if the column
> name is
> >>>>>> not
> >>>>>> found
> >>>>>> * @throws IllegalStateException
> >>>>>> * if no header mapping was provided
> >>>>>> * @throws IllegalArgumentException
> >>>>>> * if the record is inconsistent
> >>>>>> * @see #isConsistent()
> >>>>>> */
> >>>>>> public boolean getBooleanPrimitive(String name) {
> >>>>>> return Boolean.parseBoolean(this.get(name));
> >>>>>> }
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> --
> >>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
> >>>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [csv] record.get APIs for primitive types
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 02.08.2013 02:34, schrieb James Carman:
> Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
> have the functionality, especially for Strings, and it's extensible,
> we could recommend that in the Javadocs perhaps.
>
> That Converter API is screaming for some generics action!
Just for the record and because [configuration] has already been
mentioned in this thread:
One of the next points on my todo list to get [configuration] 2.0 out is
to rework the conversion framework. Currently, we have a big class doing
all kinds of conversions. I am going to change this to have an
extensible converter framework.
I would really love to make use of [beanutils], however, as soon as some
classes of another project become part of your public API, you are tight
to this project. For instance, [configuration] 1.x depends on [lang]
2.x. After the major release of [lang] 3.0, we got many requests to
update the dependency, but this was not possible in a minor release due
to binary incompatible changes - because of the changed package
structure in [lang] the API of [configuration] would also change.
Something similar can happen with [beanutils], too - work on version 2.0
has already started.
Oliver
>
> On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict <pb...@apache.org> wrote:
>> I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
>> that has these additional methods and defers them to Beanutils. We should
>> use our other Commons project to accomplish the pluggable and configurable
>> conversion. Beanutils can be an optional Maven dependency. This doesn't
>> belong in Commons Langs, because that's where the functionality was before
>> migrating to its own BeanUtils project (circa 2001ish).
>> On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
>>
>>> Perhaps it belongs in Commons Lang?
>>>
>>> Anything like this that you try to put together is going to blow up
>>> really quickly, by the way (registering new converter types, etc.). I
>>> don't see how having a few little helper methods in CSV is that big of
>>> an issue, personally.
>>>
>>> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
>>> <pa...@gmail.com> wrote:
>>>> You might want to think of a conversion addon package using Common
>>>> BeanUtils. That project is skilled at conversions from String and has
>>>> pluggable capability to customize conversion types.
>>>> On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
>>>>
>>>>> None of these methods document exceptions if the conversion fails (eg,
>>> not
>>>>> an integer). Also, how strict is the conversion? Can "x" represent
>>> boolean
>>>>> false or is that an exception?
>>>>> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>>>>>
>>>>>> I would like to note this CSVRecord addition I am planning on:
>>>>>>
>>>>>> public Boolean getBoolean(String name) {
>>>>>> public boolean getBooleanPrimitive(String name)
>>>>>>
>>>>>> The method listings are at the end of this message.
>>>>>>
>>>>>> What I want to note here is that these are conversion methods and that
>>> the
>>>>>> record still stores the values internally as Strings. I do not want to
>>>>>> Javadoc the conversion in order to give us flexibility over
>>> representation
>>>>>> if we decide to change it in the future (caching or whatnot).
>>>>>>
>>>>>> I wanted to post here in CTR mode before I or others add APIs like
>>>>>> getLong() and getLongPrimitive(). Since this is a library, I do
>>> believe we
>>>>>> should end up providing such APIs at the record level for primitives.
>>>>>>
>>>>>> /**
>>>>>> * Returns a value by name.
>>>>>> *
>>>>>> * @param name
>>>>>> * the name of the column to be retrieved.
>>>>>> * @return the column value, or {@code null} if the column name is
>>> not
>>>>>> found
>>>>>> * @throws IllegalStateException
>>>>>> * if no header mapping was provided
>>>>>> * @throws IllegalArgumentException
>>>>>> * if the record is inconsistent
>>>>>> * @see #isConsistent()
>>>>>> */
>>>>>> public Boolean getBoolean(String name) {
>>>>>> String s = this.get(name);
>>>>>> return s != null ? Boolean.valueOf(s) : null;
>>>>>> }
>>>>>>
>>>>>> /**
>>>>>> * Returns a value by name.
>>>>>> *
>>>>>> * @param name
>>>>>> * the name of the column to be retrieved.
>>>>>> * @return the column value, or {@code false} if the column name is
>>>>>> not
>>>>>> found
>>>>>> * @throws IllegalStateException
>>>>>> * if no header mapping was provided
>>>>>> * @throws IllegalArgumentException
>>>>>> * if the record is inconsistent
>>>>>> * @see #isConsistent()
>>>>>> */
>>>>>> public boolean getBooleanPrimitive(String name) {
>>>>>> return Boolean.parseBoolean(this.get(name));
>>>>>> }
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] record.get APIs for primitive types
Posted by James Carman <ja...@carmanconsulting.com>.
Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
have the functionality, especially for Strings, and it's extensible,
we could recommend that in the Javadocs perhaps.
That Converter API is screaming for some generics action!
On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict <pb...@apache.org> wrote:
> I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
> that has these additional methods and defers them to Beanutils. We should
> use our other Commons project to accomplish the pluggable and configurable
> conversion. Beanutils can be an optional Maven dependency. This doesn't
> belong in Commons Langs, because that's where the functionality was before
> migrating to its own BeanUtils project (circa 2001ish).
> On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
>
>> Perhaps it belongs in Commons Lang?
>>
>> Anything like this that you try to put together is going to blow up
>> really quickly, by the way (registering new converter types, etc.). I
>> don't see how having a few little helper methods in CSV is that big of
>> an issue, personally.
>>
>> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
>> <pa...@gmail.com> wrote:
>> > You might want to think of a conversion addon package using Common
>> > BeanUtils. That project is skilled at conversions from String and has
>> > pluggable capability to customize conversion types.
>> > On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
>> >
>> >> None of these methods document exceptions if the conversion fails (eg,
>> not
>> >> an integer). Also, how strict is the conversion? Can "x" represent
>> boolean
>> >> false or is that an exception?
>> >> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>> >>
>> >>> I would like to note this CSVRecord addition I am planning on:
>> >>>
>> >>> public Boolean getBoolean(String name) {
>> >>> public boolean getBooleanPrimitive(String name)
>> >>>
>> >>> The method listings are at the end of this message.
>> >>>
>> >>> What I want to note here is that these are conversion methods and that
>> the
>> >>> record still stores the values internally as Strings. I do not want to
>> >>> Javadoc the conversion in order to give us flexibility over
>> representation
>> >>> if we decide to change it in the future (caching or whatnot).
>> >>>
>> >>> I wanted to post here in CTR mode before I or others add APIs like
>> >>> getLong() and getLongPrimitive(). Since this is a library, I do
>> believe we
>> >>> should end up providing such APIs at the record level for primitives.
>> >>>
>> >>> /**
>> >>> * Returns a value by name.
>> >>> *
>> >>> * @param name
>> >>> * the name of the column to be retrieved.
>> >>> * @return the column value, or {@code null} if the column name is
>> not
>> >>> found
>> >>> * @throws IllegalStateException
>> >>> * if no header mapping was provided
>> >>> * @throws IllegalArgumentException
>> >>> * if the record is inconsistent
>> >>> * @see #isConsistent()
>> >>> */
>> >>> public Boolean getBoolean(String name) {
>> >>> String s = this.get(name);
>> >>> return s != null ? Boolean.valueOf(s) : null;
>> >>> }
>> >>>
>> >>> /**
>> >>> * Returns a value by name.
>> >>> *
>> >>> * @param name
>> >>> * the name of the column to be retrieved.
>> >>> * @return the column value, or {@code false} if the column name is
>> >>> not
>> >>> found
>> >>> * @throws IllegalStateException
>> >>> * if no header mapping was provided
>> >>> * @throws IllegalArgumentException
>> >>> * if the record is inconsistent
>> >>> * @see #isConsistent()
>> >>> */
>> >>> public boolean getBooleanPrimitive(String name) {
>> >>> return Boolean.parseBoolean(this.get(name));
>> >>> }
>> >>>
>> >>> Gary
>> >>>
>> >>> --
>> >>> E-Mail: garydgregory@gmail.com | ggregory@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
>> >>>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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
Re: [csv] record.get APIs for primitive types
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict <pb...@apache.org> wrote:
> I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
> that has these additional methods and defers them to Beanutils. We should
> use our other Commons project to accomplish the pluggable and configurable
> conversion. Beanutils can be an optional Maven dependency. This doesn't
> belong in Commons Langs, because that's where the functionality was before
> migrating to its own BeanUtils project (circa 2001ish).
>
Ok, the record wrapper is an interesting way to go.
Can you show such a class that just works on converting booleans as a
starting point?
Gary
> On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
>
> > Perhaps it belongs in Commons Lang?
> >
> > Anything like this that you try to put together is going to blow up
> > really quickly, by the way (registering new converter types, etc.). I
> > don't see how having a few little helper methods in CSV is that big of
> > an issue, personally.
> >
> > On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
> > <pa...@gmail.com> wrote:
> > > You might want to think of a conversion addon package using Common
> > > BeanUtils. That project is skilled at conversions from String and has
> > > pluggable capability to customize conversion types.
> > > On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
> > >
> > >> None of these methods document exceptions if the conversion fails (eg,
> > not
> > >> an integer). Also, how strict is the conversion? Can "x" represent
> > boolean
> > >> false or is that an exception?
> > >> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com>
> wrote:
> > >>
> > >>> I would like to note this CSVRecord addition I am planning on:
> > >>>
> > >>> public Boolean getBoolean(String name) {
> > >>> public boolean getBooleanPrimitive(String name)
> > >>>
> > >>> The method listings are at the end of this message.
> > >>>
> > >>> What I want to note here is that these are conversion methods and
> that
> > the
> > >>> record still stores the values internally as Strings. I do not want
> to
> > >>> Javadoc the conversion in order to give us flexibility over
> > representation
> > >>> if we decide to change it in the future (caching or whatnot).
> > >>>
> > >>> I wanted to post here in CTR mode before I or others add APIs like
> > >>> getLong() and getLongPrimitive(). Since this is a library, I do
> > believe we
> > >>> should end up providing such APIs at the record level for primitives.
> > >>>
> > >>> /**
> > >>> * Returns a value by name.
> > >>> *
> > >>> * @param name
> > >>> * the name of the column to be retrieved.
> > >>> * @return the column value, or {@code null} if the column name
> is
> > not
> > >>> found
> > >>> * @throws IllegalStateException
> > >>> * if no header mapping was provided
> > >>> * @throws IllegalArgumentException
> > >>> * if the record is inconsistent
> > >>> * @see #isConsistent()
> > >>> */
> > >>> public Boolean getBoolean(String name) {
> > >>> String s = this.get(name);
> > >>> return s != null ? Boolean.valueOf(s) : null;
> > >>> }
> > >>>
> > >>> /**
> > >>> * Returns a value by name.
> > >>> *
> > >>> * @param name
> > >>> * the name of the column to be retrieved.
> > >>> * @return the column value, or {@code false} if the column name
> is
> > >>> not
> > >>> found
> > >>> * @throws IllegalStateException
> > >>> * if no header mapping was provided
> > >>> * @throws IllegalArgumentException
> > >>> * if the record is inconsistent
> > >>> * @see #isConsistent()
> > >>> */
> > >>> public boolean getBooleanPrimitive(String name) {
> > >>> return Boolean.parseBoolean(this.get(name));
> > >>> }
> > >>>
> > >>> Gary
> > >>>
> > >>> --
> > >>> E-Mail: garydgregory@gmail.com | ggregory@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
> > >>>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [csv] record.get APIs for primitive types
Posted by Paul Benedict <pb...@apache.org>.
I can see that we should provide a decorator/delegate (CSVRecordWrapper?)
that has these additional methods and defers them to Beanutils. We should
use our other Commons project to accomplish the pluggable and configurable
conversion. Beanutils can be an optional Maven dependency. This doesn't
belong in Commons Langs, because that's where the functionality was before
migrating to its own BeanUtils project (circa 2001ish).
On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
> Perhaps it belongs in Commons Lang?
>
> Anything like this that you try to put together is going to blow up
> really quickly, by the way (registering new converter types, etc.). I
> don't see how having a few little helper methods in CSV is that big of
> an issue, personally.
>
> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
> <pa...@gmail.com> wrote:
> > You might want to think of a conversion addon package using Common
> > BeanUtils. That project is skilled at conversions from String and has
> > pluggable capability to customize conversion types.
> > On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
> >
> >> None of these methods document exceptions if the conversion fails (eg,
> not
> >> an integer). Also, how strict is the conversion? Can "x" represent
> boolean
> >> false or is that an exception?
> >> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com> wrote:
> >>
> >>> I would like to note this CSVRecord addition I am planning on:
> >>>
> >>> public Boolean getBoolean(String name) {
> >>> public boolean getBooleanPrimitive(String name)
> >>>
> >>> The method listings are at the end of this message.
> >>>
> >>> What I want to note here is that these are conversion methods and that
> the
> >>> record still stores the values internally as Strings. I do not want to
> >>> Javadoc the conversion in order to give us flexibility over
> representation
> >>> if we decide to change it in the future (caching or whatnot).
> >>>
> >>> I wanted to post here in CTR mode before I or others add APIs like
> >>> getLong() and getLongPrimitive(). Since this is a library, I do
> believe we
> >>> should end up providing such APIs at the record level for primitives.
> >>>
> >>> /**
> >>> * Returns a value by name.
> >>> *
> >>> * @param name
> >>> * the name of the column to be retrieved.
> >>> * @return the column value, or {@code null} if the column name is
> not
> >>> found
> >>> * @throws IllegalStateException
> >>> * if no header mapping was provided
> >>> * @throws IllegalArgumentException
> >>> * if the record is inconsistent
> >>> * @see #isConsistent()
> >>> */
> >>> public Boolean getBoolean(String name) {
> >>> String s = this.get(name);
> >>> return s != null ? Boolean.valueOf(s) : null;
> >>> }
> >>>
> >>> /**
> >>> * Returns a value by name.
> >>> *
> >>> * @param name
> >>> * the name of the column to be retrieved.
> >>> * @return the column value, or {@code false} if the column name is
> >>> not
> >>> found
> >>> * @throws IllegalStateException
> >>> * if no header mapping was provided
> >>> * @throws IllegalArgumentException
> >>> * if the record is inconsistent
> >>> * @see #isConsistent()
> >>> */
> >>> public boolean getBooleanPrimitive(String name) {
> >>> return Boolean.parseBoolean(this.get(name));
> >>> }
> >>>
> >>> Gary
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@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
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [csv] record.get APIs for primitive types
Posted by James Carman <ja...@carmanconsulting.com>.
Perhaps it belongs in Commons Lang?
Anything like this that you try to put together is going to blow up
really quickly, by the way (registering new converter types, etc.). I
don't see how having a few little helper methods in CSV is that big of
an issue, personally.
On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
<pa...@gmail.com> wrote:
> You might want to think of a conversion addon package using Common
> BeanUtils. That project is skilled at conversions from String and has
> pluggable capability to customize conversion types.
> On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
>
>> None of these methods document exceptions if the conversion fails (eg, not
>> an integer). Also, how strict is the conversion? Can "x" represent boolean
>> false or is that an exception?
>> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>>
>>> I would like to note this CSVRecord addition I am planning on:
>>>
>>> public Boolean getBoolean(String name) {
>>> public boolean getBooleanPrimitive(String name)
>>>
>>> The method listings are at the end of this message.
>>>
>>> What I want to note here is that these are conversion methods and that the
>>> record still stores the values internally as Strings. I do not want to
>>> Javadoc the conversion in order to give us flexibility over representation
>>> if we decide to change it in the future (caching or whatnot).
>>>
>>> I wanted to post here in CTR mode before I or others add APIs like
>>> getLong() and getLongPrimitive(). Since this is a library, I do believe we
>>> should end up providing such APIs at the record level for primitives.
>>>
>>> /**
>>> * Returns a value by name.
>>> *
>>> * @param name
>>> * the name of the column to be retrieved.
>>> * @return the column value, or {@code null} if the column name is not
>>> found
>>> * @throws IllegalStateException
>>> * if no header mapping was provided
>>> * @throws IllegalArgumentException
>>> * if the record is inconsistent
>>> * @see #isConsistent()
>>> */
>>> public Boolean getBoolean(String name) {
>>> String s = this.get(name);
>>> return s != null ? Boolean.valueOf(s) : null;
>>> }
>>>
>>> /**
>>> * Returns a value by name.
>>> *
>>> * @param name
>>> * the name of the column to be retrieved.
>>> * @return the column value, or {@code false} if the column name is
>>> not
>>> found
>>> * @throws IllegalStateException
>>> * if no header mapping was provided
>>> * @throws IllegalArgumentException
>>> * if the record is inconsistent
>>> * @see #isConsistent()
>>> */
>>> public boolean getBooleanPrimitive(String name) {
>>> return Boolean.parseBoolean(this.get(name));
>>> }
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] record.get APIs for primitive types
Posted by Paul Benedict <pa...@gmail.com>.
You might want to think of a conversion addon package using Common
BeanUtils. That project is skilled at conversions from String and has
pluggable capability to customize conversion types.
On Aug 1, 2013 6:51 PM, "Paul Benedict" <pb...@apache.org> wrote:
> None of these methods document exceptions if the conversion fails (eg, not
> an integer). Also, how strict is the conversion? Can "x" represent boolean
> false or is that an exception?
> On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com> wrote:
>
>> I would like to note this CSVRecord addition I am planning on:
>>
>> public Boolean getBoolean(String name) {
>> public boolean getBooleanPrimitive(String name)
>>
>> The method listings are at the end of this message.
>>
>> What I want to note here is that these are conversion methods and that the
>> record still stores the values internally as Strings. I do not want to
>> Javadoc the conversion in order to give us flexibility over representation
>> if we decide to change it in the future (caching or whatnot).
>>
>> I wanted to post here in CTR mode before I or others add APIs like
>> getLong() and getLongPrimitive(). Since this is a library, I do believe we
>> should end up providing such APIs at the record level for primitives.
>>
>> /**
>> * Returns a value by name.
>> *
>> * @param name
>> * the name of the column to be retrieved.
>> * @return the column value, or {@code null} if the column name is not
>> found
>> * @throws IllegalStateException
>> * if no header mapping was provided
>> * @throws IllegalArgumentException
>> * if the record is inconsistent
>> * @see #isConsistent()
>> */
>> public Boolean getBoolean(String name) {
>> String s = this.get(name);
>> return s != null ? Boolean.valueOf(s) : null;
>> }
>>
>> /**
>> * Returns a value by name.
>> *
>> * @param name
>> * the name of the column to be retrieved.
>> * @return the column value, or {@code false} if the column name is
>> not
>> found
>> * @throws IllegalStateException
>> * if no header mapping was provided
>> * @throws IllegalArgumentException
>> * if the record is inconsistent
>> * @see #isConsistent()
>> */
>> public boolean getBooleanPrimitive(String name) {
>> return Boolean.parseBoolean(this.get(name));
>> }
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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
>>
>
Re: [csv] record.get APIs for primitive types
Posted by Paul Benedict <pb...@apache.org>.
None of these methods document exceptions if the conversion fails (eg, not
an integer). Also, how strict is the conversion? Can "x" represent boolean
false or is that an exception?
On Aug 1, 2013 9:00 AM, "Gary Gregory" <ga...@gmail.com> wrote:
> I would like to note this CSVRecord addition I am planning on:
>
> public Boolean getBoolean(String name) {
> public boolean getBooleanPrimitive(String name)
>
> The method listings are at the end of this message.
>
> What I want to note here is that these are conversion methods and that the
> record still stores the values internally as Strings. I do not want to
> Javadoc the conversion in order to give us flexibility over representation
> if we decide to change it in the future (caching or whatnot).
>
> I wanted to post here in CTR mode before I or others add APIs like
> getLong() and getLongPrimitive(). Since this is a library, I do believe we
> should end up providing such APIs at the record level for primitives.
>
> /**
> * Returns a value by name.
> *
> * @param name
> * the name of the column to be retrieved.
> * @return the column value, or {@code null} if the column name is not
> found
> * @throws IllegalStateException
> * if no header mapping was provided
> * @throws IllegalArgumentException
> * if the record is inconsistent
> * @see #isConsistent()
> */
> public Boolean getBoolean(String name) {
> String s = this.get(name);
> return s != null ? Boolean.valueOf(s) : null;
> }
>
> /**
> * Returns a value by name.
> *
> * @param name
> * the name of the column to be retrieved.
> * @return the column value, or {@code false} if the column name is not
> found
> * @throws IllegalStateException
> * if no header mapping was provided
> * @throws IllegalArgumentException
> * if the record is inconsistent
> * @see #isConsistent()
> */
> public boolean getBooleanPrimitive(String name) {
> return Boolean.parseBoolean(this.get(name));
> }
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>