commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elijah Zupancic <>
Subject Re: [chain][v2] clever context - follow-up
Date Wed, 14 Sep 2011 02:12:48 GMT
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).


On Mon, Sep 12, 2011 at 12:04 AM, Simone Tripodi

> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message