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
