Hi Elijah, nice to have you with us again :-)
2013/6/26 Elijah Zupancic <eli...@zupancic.name> > Hi Benedikt, > > I made the decision to inherit from ConcurrentHashMap because the original > implementation was inheriting from HashMap. I was doing an incremental > refactoring approach and there was never a good justification for that > design rather I was trying to make evolutionary improvements. Being able to > plug in any map implementation would be a far better design. As for the > original design decision to use a HashMap, I have no insight. There were > quite a few design enigmas that I encountered, however if you look at the > date of the original project I don't think it is unusual. > Thanks for the insights! My mail was not intended to blame you. You did great work on chain. Would be great if you could manage to share your thoughts about the upcoming design changes. Benedikt > > Best of luck, > -Elijah > > > On Tue, Jun 25, 2013 at 11:24 AM, Benedikt Ritter <benerit...@gmail.com > >wrote: > > > I have created CHAIN-101 [1] > > > > Benedikt > > > > [1] https://issues.apache.org/jira/browse/CHAIN-101 > > > > Am 24.06.2013 um 20:57 schrieb Adrian Crum < > > adrian.c...@sandglass-software.com>: > > > > > I have always preferred the "has-a" approach over the "is-a" approach. > > It makes things easier to refactor down the road. > > > > > > -Adrian > > > > > > On 6/24/2013 7:30 PM, Benedikt Ritter wrote: > > >> Hi, > > >> > > >> I just wonder why ContextMap inherits from ConcurrentHashMap. This > > seems like an unnecessary restriction. The context interface makes > > explicit, that implementations do not have to be thread safe. Beside that > > we loose all thread safety a ConcurrentHashMap provides with our > > not-so-thread-safe implementations in ContextMap and ContextBase. I'd > > suggest to switch from an inheritance based approach to a delegation > based > > approach. That leaves users with the liberty to choose what ever > underlying > > Map implementation they like for their context. > > >> > > >> WDYT? > > >> Benedikt > > >> --------------------------------------------------------------------- > > >> 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 > > > > > > > -- > -Elijah > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
