commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [chain][v2] clever context - follow-up
Date Mon, 19 Sep 2011 08:01:55 GMT
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 <elijah@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 <simonetripodi@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 <pbenedict@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
>> > <simonetripodi@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 <elijah@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
>> >>> <simonetripodi@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-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message