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