[chain][v2] clever context

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.

On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta <[hidden email]> wrote:

> On 09/05/2011 08:51 AM, Simone Tripodi wrote:
>> I totally agree with you James, what is needed is just to understand
>> if break the 1.X compatibility or not...
>> I think that the discussion worths a vote call at that point, WDYT?
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>
> As a chain user, I'd be fine with that for 2.x: +1 non-binding.
>
> Cheers,
> Raman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi Paul,
agreed. I just started indeed a thread vote to accept the new codebase
as /trunk, so we can continue working toward a new releas wich
involves redesigns as well.

I would really appreciate if you and James partecipate in the vote and
could continue co-operate until next release!!!
Have a nice day, all the best,
Simo

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



On Mon, Sep 5, 2011 at 6:04 PM, Paul Benedict <[hidden email]> wrote:

> Major versions don't need to keep compatibility. Even if it is
> laudable goal to try, I rather have a better designed software and do
> 30 minutes of upgrading code than keep dragging along old decisions.
>
> On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta <[hidden email]> wrote:
>> On 09/05/2011 08:51 AM, Simone Tripodi wrote:
>>> I totally agree with you James, what is needed is just to understand
>>> if break the 1.X compatibility or not...
>>> I think that the discussion worths a vote call at that point, WDYT?
>>> Many thanks in advance, have a nice day!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>
>> As a chain user, I'd be fine with that for 2.x: +1 non-binding.
>>
>> Cheers,
>> Raman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Niall Pemberton
In reply to this post by James Carman
On Mon, Sep 5, 2011 at 12:21 PM, James Carman
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
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
<[hidden email]> wrote:

> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Elijah Zupancic
In reply to this post by Niall Pemberton
As a user of chain in a number of projects over the years, I've found
that the combination of extending Map and defining your own getter /
setter properties on the context to be ideal. With your own getters
and setters, you get better code completion and you have a more
old-fashioned entity object. With regards to extending Map, the nice
thing about it is that you can digest the contents of other contexts
easily. I can just take another context with a different signature and
do a .putAll and now I have all of its properties auto-magically -
even if not all of the getters / setters are present. This actually
saves time in projects - especially when dealing with large entity
(Context) objects with a lot of overlapping properties.

I'm all for having a asMap() method that externalizes map from the
Context implementation as long as we keep the ability to consume other
Contexts as a data source for population.

Thanks,
-Elijah

@Niall, sorry this isn't really a reply to what you wrote. I just
wanted to jump on the thread somewhere.

On Mon, Sep 5, 2011 at 5:19 PM, Niall Pemberton
<[hidden email]> wrote:

> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Niall Pemberton
In reply to this post by Simone Tripodi-2
On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <[hidden email]> 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
> <[hidden email]> wrote:
>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
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
<[hidden email]> wrote:

> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Elijah Zupancic
In reply to this post by Niall Pemberton
Hi Niall,

The source of the misunderstanding regarding the usage of chain may be
my fault. Thank you very much for piping up and letting us know some
of the history regarding the chain project.

I was under the assumption that all keys of a Context were String
because in ContextBase in the initialization method we have:

        // Retrieve the set of property descriptors for this Context class
        try {
            pd = Introspector.getBeanInfo
                (getClass()).getPropertyDescriptors();
        } catch (IntrospectionException e) {
            pd = new PropertyDescriptor[0]; // Should never happen
        }

        // Initialize the underlying Map contents
        for (int i = 0; i < pd.length; i++) {
            String name = pd[i].getName();

            // Add descriptor (ignoring getClass() and isEmpty())
            if (!("class".equals(name) || "empty".equals(name))) {
                if (descriptors == null) {
                    descriptors = new HashMap<String,
PropertyDescriptor>((pd.length - 2));
                }
                descriptors.put(name, pd[i]);
                super.put(name, singleton);
            }
        }

When you look at the method signature on FeatureDesriptor for
getName() for the following call:

String name = pd[i].getName();

you will see that the only acceptable choice is a string. Thus, if you
are subclassing ContextBase, you have to use Strings as keys in order
to make the BeanUtils glue work or you have to have a beanless
context.

I'm of the opinion that standardizing on String or <? extends
CharSequence> as the generic key for Context will make using Context
far more usable. Otherwise, if you use a non-string key, you will be
fighting many parts of the API that assume a String key.

Also, what made me assume that the contract was for String-only keys
was the fact that the test cases only use String keys (that is unless
my memory is failing me).

Thanks,
-Elijah

On Thu, Sep 8, 2011 at 1:53 PM, Niall Pemberton
<[hidden email]> wrote:

> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Niall Pemberton
On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic <[hidden email]> wrote:

> Hi Niall,
>
> The source of the misunderstanding regarding the usage of chain may be
> my fault. Thank you very much for piping up and letting us know some
> of the history regarding the chain project.
>
> I was under the assumption that all keys of a Context were String
> because in ContextBase in the initialization method we have:
>
>        // Retrieve the set of property descriptors for this Context class
>        try {
>            pd = Introspector.getBeanInfo
>                (getClass()).getPropertyDescriptors();
>        } catch (IntrospectionException e) {
>            pd = new PropertyDescriptor[0]; // Should never happen
>        }
>
>        // Initialize the underlying Map contents
>        for (int i = 0; i < pd.length; i++) {
>            String name = pd[i].getName();
>
>            // Add descriptor (ignoring getClass() and isEmpty())
>            if (!("class".equals(name) || "empty".equals(name))) {
>                if (descriptors == null) {
>                    descriptors = new HashMap<String,
> PropertyDescriptor>((pd.length - 2));
>                }
>                descriptors.put(name, pd[i]);
>                super.put(name, singleton);
>            }
>        }
>
> When you look at the method signature on FeatureDesriptor for
> getName() for the following call:
>
> String name = pd[i].getName();
>
> you will see that the only acceptable choice is a string. Thus, if you
> are subclassing ContextBase, you have to use Strings as keys in order
> to make the BeanUtils glue work or you have to have a beanless
> context.

Yes that is certainly true with the ContextBase implementation and the
use-case (Struts) that drove the development of Chain wanted exactly
that - a typed bean that could be treated as a Map.

http://svn.apache.org/repos/asf/struts/struts1/trunk/core/src/main/java/org/apache/struts/chain/contexts/

From memory (its been a while since I committed on Struts), Struts
only ever accessed its context through the bean properties and not
through the Map API. However Chain's contract never limited it to that
use-case, just provided the ContextBase implementation to make it
easy.

> I'm of the opinion that standardizing on String or <? extends
> CharSequence> as the generic key for Context will make using Context
> far more usable. Otherwise, if you use a non-string key, you will be
> fighting many parts of the API that assume a String key.

I would agree it makes it more useable where someone wants to define
their context as a bean with strongly typed properties. But you're
putting a limit on the API that isn't there and I can't think of a
single benefit that this brings. If someone chooses to use
ContextBase, then fine they accept that limitation. I don't see how
you believe it will be more useable - seems the opposite to me if I
can no longer do something that I used to be able to. I also don't
understand the comment about " fighting many parts of the API" - it
seems to me that outside of ContextBase it has no impact.

Niall

> Also, what made me assume that the contract was for String-only keys
> was the fact that the test cases only use String keys (that is unless
> my memory is failing me).
>
> Thanks,
> -Elijah
>
> On Thu, Sep 8, 2011 at 1:53 PM, Niall Pemberton
> <[hidden email]> wrote:
>> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Elijah Zupancic
Thanks for your comments Nail.

I think that I've come around to see your point after sleeping on it.
What do you think about this:

Context.java - would be defined as so:

public interface Context<K extends Object, V extends Object> extends Map<K, V>

Then ContextBase.java would be defined like so:

public class ContextBase extends ConcurrentHashMap<String, Object>
                implements Context<String, Object> {

Or we could change String to CharSequence (but I will leave that for
another discussion).

@Simo - would this negatively affect the retrieve methods that you wrote?

Thanks,
-Elijah

On Thu, Sep 8, 2011 at 5:39 PM, Niall Pemberton
<[hidden email]> wrote:

> On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic <[hidden email]> wrote:
>> Hi Niall,
>>
>> The source of the misunderstanding regarding the usage of chain may be
>> my fault. Thank you very much for piping up and letting us know some
>> of the history regarding the chain project.
>>
>> I was under the assumption that all keys of a Context were String
>> because in ContextBase in the initialization method we have:
>>
>>        // Retrieve the set of property descriptors for this Context class
>>        try {
>>            pd = Introspector.getBeanInfo
>>                (getClass()).getPropertyDescriptors();
>>        } catch (IntrospectionException e) {
>>            pd = new PropertyDescriptor[0]; // Should never happen
>>        }
>>
>>        // Initialize the underlying Map contents
>>        for (int i = 0; i < pd.length; i++) {
>>            String name = pd[i].getName();
>>
>>            // Add descriptor (ignoring getClass() and isEmpty())
>>            if (!("class".equals(name) || "empty".equals(name))) {
>>                if (descriptors == null) {
>>                    descriptors = new HashMap<String,
>> PropertyDescriptor>((pd.length - 2));
>>                }
>>                descriptors.put(name, pd[i]);
>>                super.put(name, singleton);
>>            }
>>        }
>>
>> When you look at the method signature on FeatureDesriptor for
>> getName() for the following call:
>>
>> String name = pd[i].getName();
>>
>> you will see that the only acceptable choice is a string. Thus, if you
>> are subclassing ContextBase, you have to use Strings as keys in order
>> to make the BeanUtils glue work or you have to have a beanless
>> context.
>
> Yes that is certainly true with the ContextBase implementation and the
> use-case (Struts) that drove the development of Chain wanted exactly
> that - a typed bean that could be treated as a Map.
>
> http://svn.apache.org/repos/asf/struts/struts1/trunk/core/src/main/java/org/apache/struts/chain/contexts/
>
> From memory (its been a while since I committed on Struts), Struts
> only ever accessed its context through the bean properties and not
> through the Map API. However Chain's contract never limited it to that
> use-case, just provided the ContextBase implementation to make it
> easy.
>
>> I'm of the opinion that standardizing on String or <? extends
>> CharSequence> as the generic key for Context will make using Context
>> far more usable. Otherwise, if you use a non-string key, you will be
>> fighting many parts of the API that assume a String key.
>
> I would agree it makes it more useable where someone wants to define
> their context as a bean with strongly typed properties. But you're
> putting a limit on the API that isn't there and I can't think of a
> single benefit that this brings. If someone chooses to use
> ContextBase, then fine they accept that limitation. I don't see how
> you believe it will be more useable - seems the opposite to me if I
> can no longer do something that I used to be able to. I also don't
> understand the comment about " fighting many parts of the API" - it
> seems to me that outside of ContextBase it has no impact.
>
> Niall
>
>> Also, what made me assume that the contract was for String-only keys
>> was the fact that the test cases only use String keys (that is unless
>> my memory is failing me).
>>
>> Thanks,
>> -Elijah
>>
>> On Thu, Sep 8, 2011 at 1:53 PM, Niall Pemberton
>> <[hidden email]> wrote:
>>> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <[hidden email]> 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
>>>> <[hidden email]> wrote:
>>>>> On Mon, Sep 5, 2011 at 12:21 PM, James Carman
>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <[hidden email]> wrote:
> Thanks for your comments Nail.
>
> I think that I've come around to see your point after sleeping on it.
> What do you think about this:
>
> Context.java - would be defined as so:
>
> public interface Context<K extends Object, V extends Object> extends Map<K, V>

Isn't that identical to?
public interface Context<K, V> extends Map<K, V>

> Then ContextBase.java would be defined like so:
>
> public class ContextBase extends ConcurrentHashMap<String, Object>
>                implements Context<String, Object> {

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Elijah Zupancic
Paul,

You may be right. Which one is more idiomatic?

Thanks,
-Elijah

On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <[hidden email]> wrote:

> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <[hidden email]> wrote:
>> Thanks for your comments Nail.
>>
>> I think that I've come around to see your point after sleeping on it.
>> What do you think about this:
>>
>> Context.java - would be defined as so:
>>
>> public interface Context<K extends Object, V extends Object> extends Map<K, V>
>
> Isn't that identical to?
> public interface Context<K, V> extends Map<K, V>
>
>> Then ContextBase.java would be defined like so:
>>
>> public class ContextBase extends ConcurrentHashMap<String, Object>
>>                implements Context<String, Object> {
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
I go with what I said. Extending from Object is sulfurous since all
type parameters extend at least from Object.

On Fri, Sep 9, 2011 at 1:56 PM, Elijah Zupancic <[hidden email]> wrote:

> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <[hidden email]> wrote:
>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <[hidden email]> wrote:
>>> Thanks for your comments Nail.
>>>
>>> I think that I've come around to see your point after sleeping on it.
>>> What do you think about this:
>>>
>>> Context.java - would be defined as so:
>>>
>>> public interface Context<K extends Object, V extends Object> extends Map<K, V>
>>
>> Isn't that identical to?
>> public interface Context<K, V> extends Map<K, V>
>>
>>> Then ContextBase.java would be defined like so:
>>>
>>> public class ContextBase extends ConcurrentHashMap<String, Object>
>>>                implements Context<String, Object> {
>>
>> Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
In reply to this post by Elijah Zupancic
here I am!
sorry I'm late but just terminated to have dinner :P
I think that specifying the <extending Object> can be omitted, and
Paul's suggestion is the way to go, the code is more readable.

The last added method can be improved, putting the K as argument
instead of String and <T extends V> as a strict check for output
argument:

public interface Context<K, V>
    extends Map<K, V>
{

    <T extends V> T retrieve(K key);

}

what I think is not so nice to have, is the Command, Filter, Chain,
..., notation that, getting Context as argument in their methods,
would require generics...

Lets' think about it, thanks for sharing your thoughts!!!
All the best,
Simo

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



On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic <[hidden email]> wrote:

> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <[hidden email]> wrote:
>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <[hidden email]> wrote:
>>> Thanks for your comments Nail.
>>>
>>> I think that I've come around to see your point after sleeping on it.
>>> What do you think about this:
>>>
>>> Context.java - would be defined as so:
>>>
>>> public interface Context<K extends Object, V extends Object> extends Map<K, V>
>>
>> Isn't that identical to?
>> public interface Context<K, V> extends Map<K, V>
>>
>>> Then ContextBase.java would be defined like so:
>>>
>>> public class ContextBase extends ConcurrentHashMap<String, Object>
>>>                implements Context<String, Object> {
>>
>> Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
In my personal use of Chain, I am using it as <String, Object>. So
typing as Context<K, V> is good. Though, do we need type T? Shouldn't
retrieve(K) just return V?

On Fri, Sep 9, 2011 at 2:21 PM, Simone Tripodi <[hidden email]> wrote:

> here I am!
> sorry I'm late but just terminated to have dinner :P
> I think that specifying the <extending Object> can be omitted, and
> Paul's suggestion is the way to go, the code is more readable.
>
> The last added method can be improved, putting the K as argument
> instead of String and <T extends V> as a strict check for output
> argument:
>
> public interface Context<K, V>
>    extends Map<K, V>
> {
>
>    <T extends V> T retrieve(K key);
>
> }
>
> what I think is not so nice to have, is the Command, Filter, Chain,
> ..., notation that, getting Context as argument in their methods,
> would require generics...
>
> Lets' think about it, thanks for sharing your thoughts!!!
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic <[hidden email]> wrote:
>> Paul,
>>
>> You may be right. Which one is more idiomatic?
>>
>> Thanks,
>> -Elijah
>>
>> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <[hidden email]> wrote:
>>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <[hidden email]> wrote:
>>>> Thanks for your comments Nail.
>>>>
>>>> I think that I've come around to see your point after sleeping on it.
>>>> What do you think about this:
>>>>
>>>> Context.java - would be defined as so:
>>>>
>>>> public interface Context<K extends Object, V extends Object> extends Map<K, V>
>>>
>>> Isn't that identical to?
>>> public interface Context<K, V> extends Map<K, V>
>>>
>>>> Then ContextBase.java would be defined like so:
>>>>
>>>> public class ContextBase extends ConcurrentHashMap<String, Object>
>>>>                implements Context<String, Object> {
>>>
>>> Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi Paul,
the use of that method is to automatically infer the assigned type,
instead of writing

    MyPojo myPojo = (MyPojo) context.get( "myKey" );

the retrieve method allows to

    MyPojo myPojo = context.retrieve( "myKey" );

both throw ClassCastException if types are not assignable, but with
the second method users don't have to repeat the type by casting.
Simo

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



On Fri, Sep 9, 2011 at 9:25 PM, Paul Benedict <[hidden email]> wrote:

> In my personal use of Chain, I am using it as <String, Object>. So
> typing as Context<K, V> is good. Though, do we need type T? Shouldn't
> retrieve(K) just return V?
>
> On Fri, Sep 9, 2011 at 2:21 PM, Simone Tripodi <[hidden email]> wrote:
>> here I am!
>> sorry I'm late but just terminated to have dinner :P
>> I think that specifying the <extending Object> can be omitted, and
>> Paul's suggestion is the way to go, the code is more readable.
>>
>> The last added method can be improved, putting the K as argument
>> instead of String and <T extends V> as a strict check for output
>> argument:
>>
>> public interface Context<K, V>
>>    extends Map<K, V>
>> {
>>
>>    <T extends V> T retrieve(K key);
>>
>> }
>>
>> what I think is not so nice to have, is the Command, Filter, Chain,
>> ..., notation that, getting Context as argument in their methods,
>> would require generics...
>>
>> Lets' think about it, thanks for sharing your thoughts!!!
>> All the best,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic <[hidden email]> wrote:
>>> Paul,
>>>
>>> You may be right. Which one is more idiomatic?
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <[hidden email]> wrote:
>>>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <[hidden email]> wrote:
>>>>> Thanks for your comments Nail.
>>>>>
>>>>> I think that I've come around to see your point after sleeping on it.
>>>>> What do you think about this:
>>>>>
>>>>> Context.java - would be defined as so:
>>>>>
>>>>> public interface Context<K extends Object, V extends Object> extends Map<K, V>
>>>>
>>>> Isn't that identical to?
>>>> public interface Context<K, V> extends Map<K, V>
>>>>
>>>>> Then ContextBase.java would be defined like so:
>>>>>
>>>>> public class ContextBase extends ConcurrentHashMap<String, Object>
>>>>>                implements Context<String, Object> {
>>>>
>>>> Paul
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <[hidden email]> wrote:

> Hi Paul,
> the use of that method is to automatically infer the assigned type,
> instead of writing
>
>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>
> the retrieve method allows to
>
>    MyPojo myPojo = context.retrieve( "myKey" );
>

Hmm... The inference should be automatic unless you specified Object for type V:
Context<String, String> properties = new ContextBase<String, String>();
String value = properties.retrieve("myKey");

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Elijah Zupancic
Specifying Object for V would be the most likely use case.

On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <[hidden email]> wrote:

> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <[hidden email]> wrote:
>> Hi Paul,
>> the use of that method is to automatically infer the assigned type,
>> instead of writing
>>
>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>
>> the retrieve method allows to
>>
>>    MyPojo myPojo = context.retrieve( "myKey" );
>>
>
> Hmm... The inference should be automatic unless you specified Object for type V:
> Context<String, String> properties = new ContextBase<String, String>();
> String value = properties.retrieve("myKey");
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <[hidden email]> wrote:

> Specifying Object for V would be the most likely use case.
>
> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <[hidden email]> wrote:
>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <[hidden email]> wrote:
>>> Hi Paul,
>>> the use of that method is to automatically infer the assigned type,
>>> instead of writing
>>>
>>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>>
>>> the retrieve method allows to
>>>
>>>    MyPojo myPojo = context.retrieve( "myKey" );
>>>
>>
>> Hmm... The inference should be automatic unless you specified Object for type V:
>> Context<String, String> properties = new ContextBase<String, String>();
>> String value = properties.retrieve("myKey");
>>

I don't have a good answer for the problem. I just think if you
declare types <K, V> at the class level, those should be the types
used on the methods too. The problem that I have with <T extends V> is
that it assumes a type-safe cast. You are right to say
ClassCastException was thrown for both of your examples but <T extends
V> breaks the "rule" that generics should be type-safe casts. It's
better to have the user create a bum cast and fail then the compiler
infer a bum cast and fail, imo.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi Paul,
the type inference becomes more interesting and useful if you think to
more complicated context instances, take as sample the Guava's
ClassToInstanceMap[1] where values extend a specific base type.

the  <T extends V> in the `retrieve` method reduces anyway the number
of errors, given an hypothetically  Context<String, Number> users
cannot cast to a different type:

MyPojo myPojo = (MyPojo) context.get( "myKey" );

I think anyway putting types to Context would make Filter, Command,
Chain, ... classes over engineered IMHO

best,
Simo

[1] http://s.apache.org/xfj

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



On Fri, Sep 9, 2011 at 10:20 PM, Paul Benedict <[hidden email]> wrote:

> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <[hidden email]> wrote:
>> Specifying Object for V would be the most likely use case.
>>
>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <[hidden email]> wrote:
>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <[hidden email]> wrote:
>>>> Hi Paul,
>>>> the use of that method is to automatically infer the assigned type,
>>>> instead of writing
>>>>
>>>>    MyPojo myPojo = (MyPojo) context.get( "myKey" );
>>>>
>>>> the retrieve method allows to
>>>>
>>>>    MyPojo myPojo = context.retrieve( "myKey" );
>>>>
>>>
>>> Hmm... The inference should be automatic unless you specified Object for type V:
>>> Context<String, String> properties = new ContextBase<String, String>();
>>> String value = properties.retrieve("myKey");
>>>
>
> I don't have a good answer for the problem. I just think if you
> declare types <K, V> at the class level, those should be the types
> used on the methods too. The problem that I have with <T extends V> is
> that it assumes a type-safe cast. You are right to say
> ClassCastException was thrown for both of your examples but <T extends
> V> breaks the "rule" that generics should be type-safe casts. It's
> better to have the user create a bum cast and fail then the compiler
> infer a bum cast and fail, imo.
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123