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