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 their usability.
-Adrian
Quoting Gary Gregory <garydgreg...@gmail.com>:
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() and such became
complicated. So I changed it to the inner class being backed by a HashMap,
then reduced that to a simplified version of Gray's implementation.
I apologize for the confusion.
I do not see the point of making the new objects (list, map) read-only.
Since the objects are not connected to the record, there should be no
expectancy of synchronizing the map with the record. There are "to" methods
after all. This just restricts the usability of the objects.
Gary
-Adrian
Quoting Adrian Crum <adrian.c...@sandglass-software.com>:
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.apache.org/jira/browse/CSV-104
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/22/2014 8:01 AM, Emmanuel Bourg wrote:
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 trivial to adapt the code to [csv].
Emmanuel Bourg
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
