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

Reply via email to