Hi Niall!!! ok I got you, sounds that instead of improving we put a step down on the Context. What is in your opinion the better way to manage the Context, replacing it with with Map and using generics? We thought String as a key maybe because influenced by some usecases, but as you already told it puts a limit to users needs, do you have a suggestion? Many thanks in advance! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Sep 8, 2011 at 10:53 PM, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <simonetrip...@apache.org> > wrote: >> Hi Niall, >> thanks for the hint! >> >> Anyway (DISCLAIMER: I'm putting in the original chain author's shoes, >> so I couldn't say the truth) I immagine that users would be interested >> on having, as a Context, not just a place where storing computed >> element to be shared between chain commands, but having also the >> possibility of customizations adding, for example, shared clever >> methods - take a look at the concrete default >> {{org.apache.commons.chain.impl.ContextBase}} implementation where >> there is an index of PropertiesDescriptors. > > I understand what Chain does - I was the last active Chain committer. > I was also around when it was developed for Struts. > > You miss the point I make though. Context is currently an interface > that extends the Map interface - it adds nothing, zilch, nada, rien to > the Map interface > > public interface Context extends Map { > } > > So the only thing having "Context" does is it prevents use of any > standard Map implementation. It doesn't prevent any fancy or clever > implementations you want to create - but just restricts what you can > pass through the Chain. > > Also I just looked at your changes to the Context definition and > you're now adding a second restriction - that the keys to the Context > have to now be a String. Thats great for people who effectively want a > property name - but its a new limitation for those that don't and I > don't see any benefit to that limitation. > > Niall > > >> Honestly thinking, after raw your message, I'd tend to agree that >> Map<String,Object> would be more than enough - just for the record, >> that's what we deed indeed in the Apache Cocoon3 Pipeline APIs - but >> at the same time I like the idea of having dedicated Chain API as >> shown in the current implementation. >> >> Hard to take a decision... >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Tue, Sep 6, 2011 at 2:19 AM, 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 >> >> > > --------------------------------------------------------------------- > 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
