Hi Paul, thanks for the feedback! I think that your hint is very good but I don't know why something suggests me that there are situations - like in the web subpackage - where having a typed Context would prevent undesirable runtime exception. Can I ask you please the favor of submitting a patch on CHAIN-58? Many thanks in advance! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Sep 19, 2011 at 5:18 PM, Paul Benedict <pbened...@apache.org> wrote: > Should the context in the command be parametrized? I don't think > that's such a good idea. Isn't one of the benefits of Chain is that > you don't know which context you might be getting? > > Paul > > On Mon, Sep 19, 2011 at 10:12 AM, Simone Tripodi > <simonetrip...@apache.org> wrote: >> Hi Elijah, >> I had e deeper look at your patch and raw more carefully your message, >> I just have a BIG trouble: when changing the Context interface to >> >> public interface Context<K, V> extends Map<K, V> { >> >> } >> >> you can easily note that, in Command interface (just to mention one) >> compiler complains: >> >> "Context is a raw type. References to generic type Context<K, V> >> should be parametrized" >> >> and we can not just ignore it... that's why I thought that adopting >> the signature Command<K, V, C extends Context<K, V>> in the command >> interface is not nice but needed. >> More thoughts? >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Mon, Sep 19, 2011 at 10:01 AM, Simone Tripodi >> <simonetrip...@apache.org> wrote: >>> Hi Elijah! >>> great report, thanks for your effort! :) >>> I'll have a look at your patch as soon as I get a spare time slot, >>> I'll let you know ASAP! >>> Have a nice day, all the best! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic <eli...@zupancic.name> >>> wrote: >>>> I just submitted a patch to jira as CHAIN-58. This changes Context to >>>> Context<K,V>. >>>> >>>> Thanks, >>>> -Elijah >>>> >>>> On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi >>>> <simonetrip...@apache.org>wrote: >>>> >>>>> Hi Paul! >>>>> yes it can be done, of course :) I'm not convinced anyway by the heavy >>>>> notation that, modifying the Context, would impact the Command and >>>>> Filter classes. I think it is because just a matter of taste :P >>>>> Feedbacks/suggestions/patches are welcome, if you want to provide a >>>>> solution feel free to fill an issue and attach a patch!! >>>>> TIA, all the best! >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> On Fri, Sep 16, 2011 at 11:05 PM, Paul Benedict <pbened...@apache.org> >>>>> wrote: >>>>> > The basic context should be Context<K, V> and then use interface >>>>> > composition to define other things like: >>>>> > >>>>> > public interface PropertyContext extends Context<String, Object>, >>>>> > Map<String, Object> >>>>> > >>>>> > It can be done... I think :-) >>>>> > >>>>> > Paul >>>>> > >>>>> > On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi >>>>> > <simonetrip...@apache.org> wrote: >>>>> >> Hi Elijah, >>>>> >> I spent some spare time trying to figure out how to improve the >>>>> >> Context design, I didn't have a lot of success anyway :( >>>>> >> >>>>> >> * dropping the Map inheritance makes not easy maintaining the classes >>>>> >> in the 'generic' package; >>>>> >> * adding generics in the Context to specify K,V types, makes all the >>>>> >> rest of the notation not so nice (IMHO), take a look as a sample a >>>>> >> Command<K, V, C extends Context<K, V>> :? >>>>> >> >>>>> >> Do you have more ideas? >>>>> >> Many thanks in advance, all the best! >>>>> >> Simo >>>>> >> >>>>> >> http://people.apache.org/~simonetripodi/ >>>>> >> http://www.99soft.org/ >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Wed, Sep 14, 2011 at 4:12 AM, Elijah Zupancic <eli...@zupancic.name> >>>>> wrote: >>>>> >>> Hi Everyone, >>>>> >>> >>>>> >>> I don't have any votes as I'm not a commiter, but I would still like >>>>> >>> to >>>>> add >>>>> >>> in my suggestion. >>>>> >>> >>>>> >>> After our previous exchange, I'm of the mind that we should use the >>>>> second >>>>> >>> option - that is be collection agnostic and work by composition. I may >>>>> be >>>>> >>> biased towards defined getters and setters, but I really like to be >>>>> able to >>>>> >>> use auto-complete, automatic code refactoring tools and static code >>>>> analysis >>>>> >>> tools. If we used only a Map, then the contract for a context becomes >>>>> >>> a >>>>> >>> black box of anything. I like the way it is now where you have to >>>>> implement >>>>> >>> a Map on your context or extend ContextBase. I may be biased out of >>>>> habit - >>>>> >>> if so, please convince me (by proxy everyone else). >>>>> >>> >>>>> >>> Thanks, >>>>> >>> -Elijah >>>>> >>> >>>>> >>> On Mon, Sep 12, 2011 at 12:04 AM, Simone Tripodi >>>>> >>> <simonetrip...@apache.org>wrote: >>>>> >>> >>>>> >>>> Hi all guys, >>>>> >>>> after mails and mails of discussions, I don't think there is a >>>>> >>>> general >>>>> >>>> agreement on how Context API should look alike. >>>>> >>>> At the end of the discussions I figured out that, briefly resuming, >>>>> >>>> we >>>>> >>>> have following proposals: >>>>> >>>> >>>>> >>>> * be replaced by Map; >>>>> >>>> * be Collection agnostic and work by composition. >>>>> >>>> >>>>> >>>> Please add what is missing and correct what is wrong; we need to find >>>>> >>>> a general agreement before to continue working toward the 2.0 release >>>>> >>>> :) >>>>> >>>> >>>>> >>>> TIA, all the best!!! >>>>> >>>> Simo >>>>> >>>> >>>>> >>>> http://people.apache.org/~simonetripodi/ >>>>> >>>> http://www.99soft.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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
