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 :
On Wed, Jan 22, 2014 at 11:03 AM, wrote:
There is no question your use case is convenient, but it violates th
On Wed, Jan 22, 2014 at 11:27 AM, James Ring 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 throw
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)."
On Wed, Jan 22, 2014 at 8:03 AM, wrote:
> There is no question your use case is convenient, but it violates the
> contract that
On Wed, Jan 22, 2014 at 11:03 AM, wrote:
> 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 heart of the matter indeed.
For
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 :
On Wed, Jan 22, 2014 at 10:04 AM, wrote:
I disagree.
On Wed, Jan 22, 2014 at 10:04 AM, wrote:
> 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 y
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 t
On Wed, Jan 22, 2014 at 9:40 AM, 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() and such became
> complicated.
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
ba
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 day
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.
https://issues
2014/1/22 Emmanuel Bourg
> 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 alrea
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 trivi
On Tue, Jan 21, 2014 at 8:58 AM, Emmanuel Bourg 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 you.
>
> Tha
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
th
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 key
On Tue, Jan 21, 2014 at 8:22 AM, Emmanuel Bourg wrote:
> Le 21/01/2014 14:04, Gary Gregory a écrit :
>
> > - CSVRecord implements Map
> > - CSVRecord implements Map but read-only
>
> -1
>
> > - CSVRecord implements toMap() -> Map (a plain HashMap)
>
> +0 (that's fine if the map is a copy of the r
2014/1/21 Emmanuel Bourg :
> Le 21/01/2014 14:04, Gary Gregory a écrit :
>
>> - CSVRecord implements Map
>> - CSVRecord implements Map but read-only
>
> -1
>
>> - CSVRecord implements toMap() -> Map (a plain HashMap)
>
> +0 (that's fine if the map is a copy of the record)
>
>> - CSVRecord implement
Le 21/01/2014 14:04, Gary Gregory a écrit :
> - CSVRecord implements Map
> - CSVRecord implements Map but read-only
-1
> - CSVRecord implements toMap() -> Map (a plain HashMap)
+0 (that's fine if the map is a copy of the record)
> - CSVRecord implements toMap() -> Map (a read-only HashMap)
+1
My story: There should be some kind of play between a CSVRecord and a
Map.
My current app requires only reading, not writing.
Solutions:
- CSVRecord implements Map
- CSVRecord implements Map but read-only
- CSVRecord implements toMap() -> Map (a plain HashMap)
- CSVRecord implements toMap() -> Ma
20 matches
Mail list logo
