Should the context in the command be parametrized? I don't think
that's such a good idea. Isn't one of the benefits of Chain is that
you don't know which context you might be getting?
Paul
On Mon, Sep 19, 2011 at 10: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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
