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 > >
