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 2014/01/14 23:27:59 UTC
[csv] CSVRecord implements Map
Hi All:
Any thoughts on making CSVRecord implement Map<String, String> ?
It would certainly help remove duplicate code in a use case of mine.
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] CSVRecord implements Map
Posted by sebb <se...@gmail.com>.
On 17 January 2014 08:38, Benedikt Ritter <br...@apache.org> wrote:
> 2014/1/17 sebb <se...@gmail.com>
>
>> On 17 January 2014 00:57, Gary Gregory <ga...@gmail.com> wrote:
>> > On Thu, Jan 16, 2014 at 7:24 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 16 January 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
>> >> > On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg <eb...@apache.org>
>> >> wrote:
>> >> >
>> >> >> Le 15/01/2014 14:04, Gary Gregory a écrit :
>> >> >>
>> >> >> > Uh, I want to go the other way around. See my use case.
>> >> >>
>> >> >> Why isn't this suitable to your use case? You could write:
>> >> >>
>> >> >> factory.create(record.toMap());
>> >> >>
>> >> >> and then remove the create(CSVRecord) method with the duplicated
>> >> >> implementation.
>> >> >>
>> >> >> What am I missing?
>> >> >>
>> >> >
>> >> > That would work. What is still not clean or OO is that toMap() means
>> >> > nothing when no headers are defined.
>> >> >
>> >> > I've split the record into a mapped record subclass here:
>> >> >
>> >> > https://issues.apache.org/jira/browse/CSV-104
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > We can still have toMap() implemented on top of the code now, but it
>> >> would
>> >> > have to return null if there are no headers.
>> >>
>> >> Why not return an empty Map?
>> >>
>> >
>> > An empty map is, well, empty but the record is not empty, so that's kinda
>> > confusing,
>>
>> Depends on the method Javadoc whether it is confusing or not.
>>
>> If toMap() is defined to return the empty Map if there are no column
>> names, then that is clear to me.
>>
>> AFAICT an empty map cannot be generated otherwise.
>>
>> Or is there a situation where an empty map means something usefully
>> distinct from no header names?
>>
>> > whereas null is clearly something that does exist. If toMap() is
>> > only in the subclass, then there is no problem.
>> >
>> > The alternative is to create a real map with columns name "Column1",
>> > "Column2", and so on. But then that would be confusing because
>> > record.get("Column1) would give you null whereas
>> > record.toMap().get("Column1") would give you a value. Then we get to talk
>> > about having "Column1", "Column2"... as the default column names if none
>> > are provided... kinda too clever.
>>
>> Yuk.
>>
>> > All of this to say that over time it is likely as we need to provide more
>> > APIs, and it seems easier to say null than an empty structure. First
>> > toMap(), then toProperties() and so on.
>>
>> I don't think that follows.
>>
>> > The KISS solution is toMap() -> null for unmapped records IMO.
>>
>> IMO the empty map is better.
>>
>
> To me this sounds more like IllegalStateException...
>
I would be OK with that as well.
IMO null is almost never correct as a collection or array return.
>>
>> > Gary
>> >
>> >
>> >>
>> >> > Gary
>> >> >
>> >> >
>> >> >>
>> >> >> Emmanuel Bourg
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Benedikt Ritter <br...@apache.org>.
2014/1/17 sebb <se...@gmail.com>
> On 17 January 2014 00:57, Gary Gregory <ga...@gmail.com> wrote:
> > On Thu, Jan 16, 2014 at 7:24 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 16 January 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
> >> > On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg <eb...@apache.org>
> >> wrote:
> >> >
> >> >> Le 15/01/2014 14:04, Gary Gregory a écrit :
> >> >>
> >> >> > Uh, I want to go the other way around. See my use case.
> >> >>
> >> >> Why isn't this suitable to your use case? You could write:
> >> >>
> >> >> factory.create(record.toMap());
> >> >>
> >> >> and then remove the create(CSVRecord) method with the duplicated
> >> >> implementation.
> >> >>
> >> >> What am I missing?
> >> >>
> >> >
> >> > That would work. What is still not clean or OO is that toMap() means
> >> > nothing when no headers are defined.
> >> >
> >> > I've split the record into a mapped record subclass here:
> >> >
> >> > https://issues.apache.org/jira/browse/CSV-104
> >> >
> >> > Thoughts?
> >> >
> >> > We can still have toMap() implemented on top of the code now, but it
> >> would
> >> > have to return null if there are no headers.
> >>
> >> Why not return an empty Map?
> >>
> >
> > An empty map is, well, empty but the record is not empty, so that's kinda
> > confusing,
>
> Depends on the method Javadoc whether it is confusing or not.
>
> If toMap() is defined to return the empty Map if there are no column
> names, then that is clear to me.
>
> AFAICT an empty map cannot be generated otherwise.
>
> Or is there a situation where an empty map means something usefully
> distinct from no header names?
>
> > whereas null is clearly something that does exist. If toMap() is
> > only in the subclass, then there is no problem.
> >
> > The alternative is to create a real map with columns name "Column1",
> > "Column2", and so on. But then that would be confusing because
> > record.get("Column1) would give you null whereas
> > record.toMap().get("Column1") would give you a value. Then we get to talk
> > about having "Column1", "Column2"... as the default column names if none
> > are provided... kinda too clever.
>
> Yuk.
>
> > All of this to say that over time it is likely as we need to provide more
> > APIs, and it seems easier to say null than an empty structure. First
> > toMap(), then toProperties() and so on.
>
> I don't think that follows.
>
> > The KISS solution is toMap() -> null for unmapped records IMO.
>
> IMO the empty map is better.
>
To me this sounds more like IllegalStateException...
>
> > Gary
> >
> >
> >>
> >> > Gary
> >> >
> >> >
> >> >>
> >> >> Emmanuel Bourg
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
> ---------------------------------------------------------------------
> 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] CSVRecord implements Map
Posted by sebb <se...@gmail.com>.
On 17 January 2014 00:57, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Jan 16, 2014 at 7:24 PM, sebb <se...@gmail.com> wrote:
>
>> On 16 January 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
>> > On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg <eb...@apache.org>
>> wrote:
>> >
>> >> Le 15/01/2014 14:04, Gary Gregory a écrit :
>> >>
>> >> > Uh, I want to go the other way around. See my use case.
>> >>
>> >> Why isn't this suitable to your use case? You could write:
>> >>
>> >> factory.create(record.toMap());
>> >>
>> >> and then remove the create(CSVRecord) method with the duplicated
>> >> implementation.
>> >>
>> >> What am I missing?
>> >>
>> >
>> > That would work. What is still not clean or OO is that toMap() means
>> > nothing when no headers are defined.
>> >
>> > I've split the record into a mapped record subclass here:
>> >
>> > https://issues.apache.org/jira/browse/CSV-104
>> >
>> > Thoughts?
>> >
>> > We can still have toMap() implemented on top of the code now, but it
>> would
>> > have to return null if there are no headers.
>>
>> Why not return an empty Map?
>>
>
> An empty map is, well, empty but the record is not empty, so that's kinda
> confusing,
Depends on the method Javadoc whether it is confusing or not.
If toMap() is defined to return the empty Map if there are no column
names, then that is clear to me.
AFAICT an empty map cannot be generated otherwise.
Or is there a situation where an empty map means something usefully
distinct from no header names?
> whereas null is clearly something that does exist. If toMap() is
> only in the subclass, then there is no problem.
>
> The alternative is to create a real map with columns name "Column1",
> "Column2", and so on. But then that would be confusing because
> record.get("Column1) would give you null whereas
> record.toMap().get("Column1") would give you a value. Then we get to talk
> about having "Column1", "Column2"... as the default column names if none
> are provided... kinda too clever.
Yuk.
> All of this to say that over time it is likely as we need to provide more
> APIs, and it seems easier to say null than an empty structure. First
> toMap(), then toProperties() and so on.
I don't think that follows.
> The KISS solution is toMap() -> null for unmapped records IMO.
IMO the empty map is better.
> Gary
>
>
>>
>> > Gary
>> >
>> >
>> >>
>> >> Emmanuel Bourg
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 16, 2014 at 7:24 PM, sebb <se...@gmail.com> wrote:
> On 16 January 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
> > On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg <eb...@apache.org>
> wrote:
> >
> >> Le 15/01/2014 14:04, Gary Gregory a écrit :
> >>
> >> > Uh, I want to go the other way around. See my use case.
> >>
> >> Why isn't this suitable to your use case? You could write:
> >>
> >> factory.create(record.toMap());
> >>
> >> and then remove the create(CSVRecord) method with the duplicated
> >> implementation.
> >>
> >> What am I missing?
> >>
> >
> > That would work. What is still not clean or OO is that toMap() means
> > nothing when no headers are defined.
> >
> > I've split the record into a mapped record subclass here:
> >
> > https://issues.apache.org/jira/browse/CSV-104
> >
> > Thoughts?
> >
> > We can still have toMap() implemented on top of the code now, but it
> would
> > have to return null if there are no headers.
>
> Why not return an empty Map?
>
An empty map is, well, empty but the record is not empty, so that's kinda
confusing, whereas null is clearly something that does exist. If toMap() is
only in the subclass, then there is no problem.
The alternative is to create a real map with columns name "Column1",
"Column2", and so on. But then that would be confusing because
record.get("Column1) would give you null whereas
record.toMap().get("Column1") would give you a value. Then we get to talk
about having "Column1", "Column2"... as the default column names if none
are provided... kinda too clever.
All of this to say that over time it is likely as we need to provide more
APIs, and it seems easier to say null than an empty structure. First
toMap(), then toProperties() and so on.
The KISS solution is toMap() -> null for unmapped records IMO.
Gary
>
> > Gary
> >
> >
> >>
> >> Emmanuel Bourg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
> ---------------------------------------------------------------------
> 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] CSVRecord implements Map
Posted by sebb <se...@gmail.com>.
On 16 January 2014 20:58, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
>> Le 15/01/2014 14:04, Gary Gregory a écrit :
>>
>> > Uh, I want to go the other way around. See my use case.
>>
>> Why isn't this suitable to your use case? You could write:
>>
>> factory.create(record.toMap());
>>
>> and then remove the create(CSVRecord) method with the duplicated
>> implementation.
>>
>> What am I missing?
>>
>
> That would work. What is still not clean or OO is that toMap() means
> nothing when no headers are defined.
>
> I've split the record into a mapped record subclass here:
>
> https://issues.apache.org/jira/browse/CSV-104
>
> Thoughts?
>
> We can still have toMap() implemented on top of the code now, but it would
> have to return null if there are no headers.
Why not return an empty Map?
> Gary
>
>
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/01/2014 21:58, Gary Gregory a écrit :
> That would work. What is still not clean or OO is that toMap() means
> nothing when no headers are defined.
Well, so be it.
> I've split the record into a mapped record subclass here:
>
> https://issues.apache.org/jira/browse/CSV-104
>
> Thoughts?
I'm not sure to like it. I assume a header is used in a majority of
cases, so people will end up using CSVMappedRecord almost exclusively
and that won't make a big difference with the current CSVRecord.
Also, I had some hope to later be able to parametrize the format and
have an automatic object creation on parsing (using annotations).
Something like:
CSVFormat<Person> format = CSVFormat.DEFAULT.withType(Person.class);
for (Person person : format.parse(in)) {
...
}
It's ruined by the record type parameter on CSVFormat.
> We can still have toMap() implemented on top of the code now, but it would
> have to return null if there are no headers.
That's fine for me.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 15/01/2014 14:04, Gary Gregory a écrit :
>
> > Uh, I want to go the other way around. See my use case.
>
> Why isn't this suitable to your use case? You could write:
>
> factory.create(record.toMap());
>
> and then remove the create(CSVRecord) method with the duplicated
> implementation.
>
> What am I missing?
>
That would work. What is still not clean or OO is that toMap() means
nothing when no headers are defined.
I've split the record into a mapped record subclass here:
https://issues.apache.org/jira/browse/CSV-104
Thoughts?
We can still have toMap() implemented on top of the code now, but it would
have to return null if there are no headers.
Gary
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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] CSVRecord implements Map
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 15/01/2014 14:04, Gary Gregory a écrit :
> Uh, I want to go the other way around. See my use case.
Why isn't this suitable to your use case? You could write:
factory.create(record.toMap());
and then remove the create(CSVRecord) method with the duplicated
implementation.
What am I missing?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jan 15, 2014 at 1:17 AM, Benedikt Ritter <br...@apache.org> wrote:
> A wrapper of some kind like Adrian suggested sounds like the way to go
> here. Maybe we could have something like:
>
> Map<String, String> map = CSVRecordUtils.toMap(record);
>
Uh, I want to go the other way around. See my use case.
Gary
>
> Benedikt
>
> 2014/1/15 Gary Gregory <ga...@gmail.com>
>
> > I have a complex immutable class with a constructor that takes many
> fields.
> >
> > I have a factory that builds instances of this class.
> >
> > At runtime, some of the data to build the objects come from CSVRecord
> > objects.
> >
> > At other times, like for tests, I want build sometimes I build the
> objects
> > from CSVRecord and sometimes from Map objects. The factory uses the Map
> > like a CSVRecord. This let's me build simple, medium and large objects
> > using a Map, which is handy for the test, without having to deal with all
> > of the fields in a real record.
> >
> > Right now, I have duplicate looking code in the factory methods since
> > CSVRecord and Map<String, String> are not friends.
> >
> > Hence my request. Also consider that one cannot do 'new CSVRecord()' like
> > one can 'new HashMap<String, String>()'.
> >
> > Thanks,
> > Gary
> >
> >
> > On Tue, Jan 14, 2014 at 6:11 PM, Emmanuel Bourg <eb...@apache.org>
> wrote:
> >
> > > I'm not fond of the idea at the first glance. What is your use case?
> > >
> > > Emmanuel
> > >
> > >
> > > Le 14/01/2014 23:27, Gary Gregory a écrit :
> > > > Hi All:
> > > >
> > > > Any thoughts on making CSVRecord implement Map<String, String> ?
> > > >
> > > > It would certainly help remove duplicate code in a use case of mine.
> > > >
> > > > Gary
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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] CSVRecord implements Map
Posted by Adrian Crum <ad...@sandglass-software.com>.
CSVRecordMap implements Map<String, String> {
CSVRecordMap(CSVRecord record) {
}
}
Use the Map implementation to access the record in a Map-like way, use
the CSVRecord instance to access the record in a List-like way.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/16/2014 1:04 AM, Gary Gregory wrote:
> Maybe we _should_ revisit splitting the record class. Now, we have the
> following slots:
>
> CSVRecord:
> comment : String
> mapping : Map<String, Integer>
> recordNumber : long
> values : String[]
>
> If we take out mapping and put in it a subclass, that reduces the "size" of
> the plain record by 25%:
>
> CSVRecord:
> comment : String
> recordNumber : long
> values : String[]
>
> CSVRecordMap extends CSVRecord
> mapping : Map<String, Integer>
>
> or:
>
> CSVRecordMap extends CSVRecord implements Map<String, String>
> mapping : Map<String, Integer>
>
>
> Thoughts?
>
> Gary
>
>
> On Wed, Jan 15, 2014 at 11:22 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
>> Le 15/01/2014 07:17, Benedikt Ritter a écrit :
>>> A wrapper of some kind like Adrian suggested sounds like the way to go
>>> here. Maybe we could have something like:
>>>
>>> Map<String, String> map = CSVRecordUtils.toMap(record);
>>
>> I had something like that in mind too, but I would rather use
>> record.toMap() and avoid exposing a new class.
>>
>> 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] CSVRecord implements Map
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/01/2014 07:04, Gary Gregory a écrit :
> Thoughts?
I don't mind improving how the internal state of CSVRecord is stored,
but that shouldn't cause a regression in the usability and make it
harder to access the record by key or by index.
I don't think the size of a CSVRecord is really an issue. The actual
mapping is already shared between the instances, and a CSVRecord is a
very short lived object in general.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Benedikt Ritter <br...@apache.org>.
2014/1/16 Gary Gregory <ga...@gmail.com>
> Maybe we _should_ revisit splitting the record class. Now, we have the
> following slots:
>
> CSVRecord:
> comment : String
> mapping : Map<String, Integer>
> recordNumber : long
> values : String[]
>
> If we take out mapping and put in it a subclass, that reduces the "size" of
> the plain record by 25%:
>
> CSVRecord:
> comment : String
> recordNumber : long
> values : String[]
>
> CSVRecordMap extends CSVRecord
> mapping : Map<String, Integer>
>
> or:
>
> CSVRecordMap extends CSVRecord implements Map<String, String>
> mapping : Map<String, Integer>
>
>
> Thoughts?
>
Sounds like a nice idea. We would have to change how the parsing works,
because currently CSVParser implements Iterable<CSVRecord>. We would need a
method that returns an Iterable<CSVRecord> and one that returns an
Iteable<CSVRecordMap> (or MappedCSVRecord?).
We had this discussion [1] a while back, where Paul Benedict mentioned that
the whole design of a Parser that is an Iterable may not be completely
sound.
Benedikt
[1] http://markmail.org/message/occadenoj2nycneh
>
> Gary
>
>
> On Wed, Jan 15, 2014 at 11:22 AM, Emmanuel Bourg <eb...@apache.org>
> wrote:
>
> > Le 15/01/2014 07:17, Benedikt Ritter a écrit :
> > > A wrapper of some kind like Adrian suggested sounds like the way to go
> > > here. Maybe we could have something like:
> > >
> > > Map<String, String> map = CSVRecordUtils.toMap(record);
> >
> > I had something like that in mind too, but I would rather use
> > record.toMap() and avoid exposing a new class.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > 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] CSVRecord implements Map
Posted by Gary Gregory <ga...@gmail.com>.
Maybe we _should_ revisit splitting the record class. Now, we have the
following slots:
CSVRecord:
comment : String
mapping : Map<String, Integer>
recordNumber : long
values : String[]
If we take out mapping and put in it a subclass, that reduces the "size" of
the plain record by 25%:
CSVRecord:
comment : String
recordNumber : long
values : String[]
CSVRecordMap extends CSVRecord
mapping : Map<String, Integer>
or:
CSVRecordMap extends CSVRecord implements Map<String, String>
mapping : Map<String, Integer>
Thoughts?
Gary
On Wed, Jan 15, 2014 at 11:22 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 15/01/2014 07:17, Benedikt Ritter a écrit :
> > A wrapper of some kind like Adrian suggested sounds like the way to go
> > here. Maybe we could have something like:
> >
> > Map<String, String> map = CSVRecordUtils.toMap(record);
>
> I had something like that in mind too, but I would rather use
> record.toMap() and avoid exposing a new class.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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] CSVRecord implements Map
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 15/01/2014 07:17, Benedikt Ritter a écrit :
> A wrapper of some kind like Adrian suggested sounds like the way to go
> here. Maybe we could have something like:
>
> Map<String, String> map = CSVRecordUtils.toMap(record);
I had something like that in mind too, but I would rather use
record.toMap() and avoid exposing a new class.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Benedikt Ritter <br...@apache.org>.
A wrapper of some kind like Adrian suggested sounds like the way to go
here. Maybe we could have something like:
Map<String, String> map = CSVRecordUtils.toMap(record);
Benedikt
2014/1/15 Gary Gregory <ga...@gmail.com>
> I have a complex immutable class with a constructor that takes many fields.
>
> I have a factory that builds instances of this class.
>
> At runtime, some of the data to build the objects come from CSVRecord
> objects.
>
> At other times, like for tests, I want build sometimes I build the objects
> from CSVRecord and sometimes from Map objects. The factory uses the Map
> like a CSVRecord. This let's me build simple, medium and large objects
> using a Map, which is handy for the test, without having to deal with all
> of the fields in a real record.
>
> Right now, I have duplicate looking code in the factory methods since
> CSVRecord and Map<String, String> are not friends.
>
> Hence my request. Also consider that one cannot do 'new CSVRecord()' like
> one can 'new HashMap<String, String>()'.
>
> Thanks,
> Gary
>
>
> On Tue, Jan 14, 2014 at 6:11 PM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> > I'm not fond of the idea at the first glance. What is your use case?
> >
> > Emmanuel
> >
> >
> > Le 14/01/2014 23:27, Gary Gregory a écrit :
> > > Hi All:
> > >
> > > Any thoughts on making CSVRecord implement Map<String, String> ?
> > >
> > > It would certainly help remove duplicate code in a use case of mine.
> > >
> > > Gary
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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] CSVRecord implements Map
Posted by Gary Gregory <ga...@gmail.com>.
I have a complex immutable class with a constructor that takes many fields.
I have a factory that builds instances of this class.
At runtime, some of the data to build the objects come from CSVRecord
objects.
At other times, like for tests, I want build sometimes I build the objects
from CSVRecord and sometimes from Map objects. The factory uses the Map
like a CSVRecord. This let's me build simple, medium and large objects
using a Map, which is handy for the test, without having to deal with all
of the fields in a real record.
Right now, I have duplicate looking code in the factory methods since
CSVRecord and Map<String, String> are not friends.
Hence my request. Also consider that one cannot do 'new CSVRecord()' like
one can 'new HashMap<String, String>()'.
Thanks,
Gary
On Tue, Jan 14, 2014 at 6:11 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> I'm not fond of the idea at the first glance. What is your use case?
>
> Emmanuel
>
>
> Le 14/01/2014 23:27, Gary Gregory a écrit :
> > Hi All:
> >
> > Any thoughts on making CSVRecord implement Map<String, String> ?
> >
> > It would certainly help remove duplicate code in a use case of mine.
> >
> > Gary
> >
>
>
> ---------------------------------------------------------------------
> 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] CSVRecord implements Map
Posted by Emmanuel Bourg <eb...@apache.org>.
I'm not fond of the idea at the first glance. What is your use case?
Emmanuel
Le 14/01/2014 23:27, Gary Gregory a écrit :
> Hi All:
>
> Any thoughts on making CSVRecord implement Map<String, String> ?
>
> It would certainly help remove duplicate code in a use case of mine.
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jan 15, 2014 at 4:19 AM, Jörg Schaible <joerg.schaible@swisspost.com
> wrote:
> Hi Adrian,
>
> Adrian Crum wrote:
>
> > That would only work if the CSV file had column names.
>
> No, it works only if it has *unique* column names. Guess, this is normally
> the case, but there's no such requirement.
>
If your column names are not unique, what good are they?
This reminds me of the discussion of whether we should have two classes: a
positional record (int access) and a mapped record (String access) or just
the one we currently have (combo).
We already provide String access which is a subset of Map access. So the
question is, why is wrong to extend the String access we have now to Map
access?
Gary
>
> > Maybe make a
> > class that implements Map and contains a CSVRecord - so it's optional.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> 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] CSVRecord implements Map
Posted by Jörg Schaible <jo...@swisspost.com>.
Hi Adrian,
Adrian Crum wrote:
> That would only work if the CSV file had column names.
No, it works only if it has *unique* column names. Guess, this is normally
the case, but there's no such requirement.
> Maybe make a
> class that implements Map and contains a CSVRecord - so it's optional.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [csv] CSVRecord implements Map
Posted by Adrian Crum <ad...@sandglass-software.com>.
That would only work if the CSV file had column names. Maybe make a
class that implements Map and contains a CSVRecord - so it's optional.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/14/2014 5:27 PM, Gary Gregory wrote:
> Hi All:
>
> Any thoughts on making CSVRecord implement Map<String, String> ?
>
> It would certainly help remove duplicate code in a use case of mine.
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org