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 you.
>
> That's an independent copy of the structure of the record. Changes to
> the map are not reflected in the record (and shouldn't).
>
OK, that's what the impl does now, it's clear and simple.
>
> An alternative would be a Map backed by the record. Calling
> map.get("foo") would translate to record.get("foo"), etc. We did
> something similar in [configuration] (read/write here).
>
This kind of complication is unnecessary IMO, why not just have the record
implement Map? The only wrinkle is for unmapped records. Stepping back from
that leads to having a record vs. mapped record classes, which seems to
make the code more complicated. At least my experiment with generics was
not ideal (see JIRA), but it could be made simpler by just doing a type
cast instead of using generics. IF we think the 80/20 rule applies and that
80% of CSV files are going to be mapped, then record implementing Map makes
sense, it will satisfy most of the cases with the simplest design.
Gary
>
> http://svn.apache.org/repos/asf/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ConfigurationMap.java
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
