As a user of chain in a number of projects over the years, I've found that the combination of extending Map and defining your own getter / setter properties on the context to be ideal. With your own getters and setters, you get better code completion and you have a more old-fashioned entity object. With regards to extending Map, the nice thing about it is that you can digest the contents of other contexts easily. I can just take another context with a different signature and do a .putAll and now I have all of its properties auto-magically - even if not all of the getters / setters are present. This actually saves time in projects - especially when dealing with large entity (Context) objects with a lot of overlapping properties.
I'm all for having a asMap() method that externalizes map from the Context implementation as long as we keep the ability to consume other Contexts as a data source for population. Thanks, -Elijah @Niall, sorry this isn't really a reply to what you wrote. I just wanted to jump on the thread somewhere. On Mon, Sep 5, 2011 at 5:19 PM, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Mon, Sep 5, 2011 at 12:21 PM, James Carman > <ja...@carmanconsulting.com> wrote: >> I agree with Paul here. Extending Map (or any other class for that >> matter) when what you really want to do is encapsulate it is silly. >> Is the Context really meant to be used in any place where a Map can be >> used? I would think not. > > I always thought the other way. I never understood why context wasn't > just a Map, rather than a new Chain specific type extending Map. > > Using Map has its advantages. Firstly the contract it provides besides > get/put are useful operations on the context (containsKey(), size(), > entrySet() etc.etc) , secondly (if it was a "plain" Map) there are > standard implementations & wrappers that can be used giving features > such as concurrency, ready-only etc. and thirdly tools & libraries > understand how to operate on a Map. > > Niall > >> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <pbened...@apache.org> wrote: >>> I want to get rid of it extending map. Have it define as asMap() >>> function instead. Especially since JDK 8 is bringing in extension >>> methods, which adds new (and default) methods to all collections, it >>> won't look very nice. Let's make a break now. >>> >>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <rocketra...@fastmail.fm> wrote: >>>> On 09/04/2011 04:00 PM, James Carman wrote: >>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <simonetrip...@apache.org> >>>>> wrote: >>>>>> >>>>>> That is able to 'auto-cast' the retrieved object while Map#get() not. >>>>>> >>>>> >>>>> I believe the feature is actually called "type inference", not >>>>> "auto-cast." :) >>>> >>>> Thanks for the explanation... I see now that via the generic method >>>> the compiler infers the return type from the assignment type. >>>> >>>> Cheers, >>>> Raman >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> >> > > --------------------------------------------------------------------- > 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
