Hi Niall,
thanks for the hint!
Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
so I couldn't say the truth) I immagine that users would be interested
on having, as a Context, not just a place where storing computed
element to be shared between chain commands, but having also the
possibility of customizations adding, for example, shared clever
methods - take a look at the concrete default
{{org.apache.commons.chain.impl.ContextBase}} implementation where
there is an index of PropertiesDescriptors.
Honestly thinking, after raw your message, I'd tend to agree that
Map<String,Object> would be more than enough - just for the record,
that's what we deed indeed in the Apache Cocoon3 Pipeline APIs - but
at the same time I like the idea of having dedicated Chain API as
shown in the current implementation.
Hard to take a decision...
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Sep 6, 2011 at 2:19 AM, Niall Pemberton
<niall.pember...@gmail.com> wrote:
> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> I agree with Paul here. Extending Map (or any other class for that
>> matter) when what you really want to do is encapsulate it is silly.
>> Is the Context really meant to be used in any place where a Map can be
>> used? I would think not.
>
> I always thought the other way. I never understood why context wasn't
> just a Map, rather than a new Chain specific type extending Map.
>
> Using Map has its advantages. Firstly the contract it provides besides
> get/put are useful operations on the context (containsKey(), size(),
> entrySet() etc.etc) , secondly (if it was a "plain" Map) there are
> standard implementations & wrappers that can be used giving features
> such as concurrency, ready-only etc. and thirdly tools & libraries
> understand how to operate on a Map.
>
> Niall
>
>> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <pbened...@apache.org> wrote:
>>> I want to get rid of it extending map. Have it define as asMap()
>>> function instead. Especially since JDK 8 is bringing in extension
>>> methods, which adds new (and default) methods to all collections, it
>>> won't look very nice. Let's make a break now.
>>>
>>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <rocketra...@fastmail.fm> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <simonetrip...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>>>>
>>>>>
>>>>> I believe the feature is actually called "type inference", not
>>>>> "auto-cast." :)
>>>>
>>>> Thanks for the explanation... I see now that via the generic method
>>>> the compiler infers the return type from the assignment type.
>>>>
>>>> Cheers,
>>>> Raman
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
