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
