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
