Hi Simo,
Funny, I don't believe think that compiler complained at all. I will double
check soon and try some other compilers and let you know soon.
Thanks,
-Elijah
On Mon, Sep 19, 2011 at 8:12 AM, Simone Tripodi <simonetrip...@apache.org>wrote:
> Hi Elijah,
> I had e deeper look at your patch and raw more carefully your message,
> I just have a BIG trouble: when changing the Context interface to
>
> public interface Context<K, V> extends Map<K, V> {
>
> }
>
> you can easily note that, in Command interface (just to mention one)
> compiler complains:
>
> "Context is a raw type. References to generic type Context<K, V>
> should be parametrized"
>
> and we can not just ignore it... that's why I thought that adopting
> the signature Command<K, V, C extends Context<K, V>> in the command
> interface is not nice but needed.
> More thoughts?
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 19, 2011 at 10:01 AM, Simone Tripodi
> <simonetrip...@apache.org> wrote:
> > Hi Elijah!
> > great report, thanks for your effort! :)
> > I'll have a look at your patch as soon as I get a spare time slot,
> > I'll let you know ASAP!
> > Have a nice day, all the best!
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> >
> >
> > On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic <eli...@zupancic.name>
> wrote:
> >> 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
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
