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
