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
Date Thu, 08 Sep 2011 21:09:49 GMT
Hi Niall!!!
ok I got you, sounds that instead of improving we put a step down on
the Context.
What is in your opinion the better way to manage the Context,
replacing it with with Map and using generics?
We thought String as a key maybe because influenced by some usecases,
but as you already told it puts a limit to users needs, do you have a
suggestion?
Many thanks in advance!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Sep 8, 2011 at 10:53 PM, Niall Pemberton
<niall.pemberton@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <simonetripodi@apache.org> wrote:
>> 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.
>
> I understand what Chain does - I was the last active Chain committer.
> I was also around when it was developed for Struts.
>
> You miss the point I make though. Context is currently an interface
> that extends the Map interface - it adds nothing, zilch, nada, rien to
> the Map interface
>
> public interface Context extends Map {
> }
>
> So the only thing having "Context" does is it prevents use of any
> standard Map implementation. It doesn't prevent any fancy or clever
> implementations you want to create - but just restricts what you can
> pass through the Chain.
>
> Also I just looked at your changes to the Context definition and
> you're now adding a second restriction - that the keys to the Context
> have to now be a String. Thats great for people who effectively want a
> property name - but its a new limitation for those that don't and I
> don't see any benefit to that limitation.
>
> Niall
>
>
>> 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.pemberton@gmail.com> wrote:
>>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>>> <james@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 <pbenedict@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 <rocketraman@fastmail.fm>
wrote:
>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <simonetripodi@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-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
>>
>>
>
> ---------------------------------------------------------------------
> 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