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
