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 <garydgreg...@gmail.com>

> On Thu, Aug 1, 2013 at 10:30 AM, sebb <seb...@gmail.com> wrote:
>
> > On 1 August 2013 15:21, Emmanuel Bourg <ebo...@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-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: 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
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Reply via email to