Le 21/01/2014 15:08, Gary Gregory a écrit :
This kind of complication is unnecessary IMO, why not just have the record
implement Map?
Because a record is neither a List nor a Map.
A map decorator isn't that complicated, and the work has already been
done in [configuration]. It would be
2014/1/22 Emmanuel Bourg ebo...@apache.org
Le 21/01/2014 15:08, Gary Gregory a écrit :
This kind of complication is unnecessary IMO, why not just have the
record
implement Map?
Because a record is neither a List nor a Map.
+1
A map decorator isn't that complicated, and the work has
I agree with Emmanuel. We don't want CSVRecord to devolve into a god
class that tries to be everything to everybody. Do only one thing, and
do it really well is the design pattern I prefer.
I created a patch for the design I proposed a few days ago. Please
consider using it.
Le 22/01/2014 14:41, Adrian Crum a écrit :
I agree with Emmanuel. We don't want CSVRecord to devolve into a god
class that tries to be everything to everybody. Do only one thing, and
do it really well is the design pattern I prefer.
I created a patch for the design I proposed a few days ago.
CORRECTION: The patch in the Jira issue is a simplified version of
Gary's implementation.
I started with the design I proposed - an inner class Map
implementation backed by CSVRecord, but then implementing entrySet()
and such became complicated. So I changed it to the inner class being
On Wed, Jan 22, 2014 at 9:40 AM, adrian.c...@sandglass-software.com wrote:
CORRECTION: The patch in the Jira issue is a simplified version of Gary's
implementation.
I started with the design I proposed - an inner class Map implementation
backed by CSVRecord, but then implementing entrySet()
I disagree. If the CSV record is read-only, then the List and Map
representations of the CSV record should be read-only too. Making
those representations writable is confusing - it gives the impression
you are modifying the CSV record when in fact you are not.
I don't see how it restricts
On Wed, Jan 22, 2014 at 10:04 AM, adrian.c...@sandglass-software.comwrote:
I disagree. If the CSV record is read-only, then the List and Map
representations of the CSV record should be read-only too. Making those
representations writable is confusing - it gives the impression you are
There is no question your use case is convenient, but it violates the
contract that a CSV record is read-only. Calling put() on a CSV record
is a mutating operation.
So, is a CSV record read-only or not?
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 10:04
On Wed, Jan 22, 2014 at 11:03 AM, adrian.c...@sandglass-software.comwrote:
There is no question your use case is convenient, but it violates the
contract that a CSV record is read-only. Calling put() on a CSV record is a
mutating operation.
So, is a CSV record read-only or not?
That the
On Wed, Jan 22, 2014 at 11:27 AM, James Ring s...@jdns.org wrote:
There is nothing that says Map must be mutable, even the javadoc says:
put - Associates the specified value with the specified key in this
map (optional operation).
Hm, good point, so we could have CSVRecord implement Map but
Personally, I would like to see CSV record made mutable. You could get
one from the parser, make a few changes to it, then pass it to the
printer.
-Adrian
Quoting Gary Gregory garydgreg...@gmail.com:
On Wed, Jan 22, 2014 at 11:03 AM, adrian.c...@sandglass-software.comwrote:
There is no
My story: There should be some kind of play between a CSVRecord and a
MapString, String.
My current app requires only reading, not writing.
Solutions:
- CSVRecord implements MapString, String
- CSVRecord implements MapString, String but read-only
- CSVRecord implements toMap() - MapString,
Le 21/01/2014 14:04, Gary Gregory a écrit :
- CSVRecord implements MapString, String
- CSVRecord implements MapString, String but read-only
-1
- CSVRecord implements toMap() - MapString, String (a plain HashMap)
+0 (that's fine if the map is a copy of the record)
- CSVRecord implements
2014/1/21 Emmanuel Bourg ebo...@apache.org:
Le 21/01/2014 14:04, Gary Gregory a écrit :
- CSVRecord implements MapString, String
- CSVRecord implements MapString, String but read-only
-1
- CSVRecord implements toMap() - MapString, String (a plain HashMap)
+0 (that's fine if the map is a
On Tue, Jan 21, 2014 at 8:22 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 21/01/2014 14:04, Gary Gregory a écrit :
- CSVRecord implements MapString, String
- CSVRecord implements MapString, String but read-only
-1
- CSVRecord implements toMap() - MapString, String (a plain HashMap)
It might help to step back from the story and look at it from the
perspective of a Commons CSV user who is familiar with using Maps.
How should a Map derived from a CSVRecord behave?
What happens with the put() and putAll() methods?
What happens when get() and put() are called with invalid
Le 21/01/2014 14:44, Gary Gregory a écrit :
That's what the current impl does: a new HashMap with String keys and
String values. Since Strings are immutable, they do not need to be a
'copy'. Unless I misunderstand you.
That's an independent copy of the structure of the record. Changes to
the
On Tue, Jan 21, 2014 at 8:58 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 21/01/2014 14:44, Gary Gregory a écrit :
That's what the current impl does: a new HashMap with String keys and
String values. Since Strings are immutable, they do not need to be a
'copy'. Unless I misunderstand
2014/1/17 sebb seb...@gmail.com
On 17 January 2014 00:57, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:24 PM, sebb seb...@gmail.com wrote:
On 16 January 2014 20:58, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg
On 17 January 2014 08:38, Benedikt Ritter brit...@apache.org wrote:
2014/1/17 sebb seb...@gmail.com
On 17 January 2014 00:57, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:24 PM, sebb seb...@gmail.com wrote:
On 16 January 2014 20:58, Gary Gregory
CSVRecordMap implements MapString, 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
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
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
On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg ebo...@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
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
On 16 January 2014 20:58, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg ebo...@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
On Thu, Jan 16, 2014 at 7:24 PM, sebb seb...@gmail.com wrote:
On 16 January 2014 20:58, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg ebo...@apache.org
wrote:
Le 15/01/2014 14:04, Gary Gregory a écrit :
Uh, I want to go the other way
On 17 January 2014 00:57, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:24 PM, sebb seb...@gmail.com wrote:
On 16 January 2014 20:58, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, Jan 16, 2014 at 7:49 AM, Emmanuel Bourg ebo...@apache.org
wrote:
Le 15/01/2014
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.
On Wed, Jan 15, 2014 at 1:17 AM, Benedikt Ritter brit...@apache.org wrote:
A wrapper of some kind like Adrian suggested sounds like the way to go
here. Maybe we could have something like:
MapString, String map = CSVRecordUtils.toMap(record);
Uh, I want to go the other way around. See my use
On Wed, Jan 15, 2014 at 4:19 AM, Jörg Schaible joerg.schai...@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.
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:
MapString, String map = CSVRecordUtils.toMap(record);
I had something like that in mind too, but I would rather use
record.toMap()
Maybe we _should_ revisit splitting the record class. Now, we have the
following slots:
CSVRecord:
comment : String
mapping : MapString, 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:
2014/1/16 Gary Gregory garydgreg...@gmail.com
Maybe we _should_ revisit splitting the record class. Now, we have the
following slots:
CSVRecord:
comment : String
mapping : MapString, Integer
recordNumber : long
values : String[]
If we take out mapping and put in it a subclass, that
Hi All:
Any thoughts on making CSVRecord implement MapString, String ?
It would certainly help remove duplicate code in a use case of mine.
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/
JUnit in
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
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 MapString, String ?
It would certainly help remove duplicate code in a use case of mine.
Gary
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
A wrapper of some kind like Adrian suggested sounds like the way to go
here. Maybe we could have something like:
MapString, String map = CSVRecordUtils.toMap(record);
Benedikt
2014/1/15 Gary Gregory garydgreg...@gmail.com
I have a complex immutable class with a constructor that takes many
40 matches
Mail list logo
