You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@apache.org> on 2011/09/04 11:22:25 UTC
[chain][v2] clever context
Hi all guys,
I think that generics could help us on improving the Context class;
I'm not particularly happy having it extending Map - it is needed
anyway for backward compatibility - but it is clear that Context is a
place where storing/retrieving objects identified by a key.
I propose adding two helper methods
/** @since 2.0 */
<T> T retrieve( String key );
/** @since 2.0 */
<T> void store( String key, T object );
that would help users avoid the redundant code of type cast/checking
when assignments are already known (it throws a ClassCastException if
types are not assignable).
At the same time, old pattern is supported, users can choose their
preferred way to go, depending on their needs.
WDYT?
Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
thanks James!
as you can notice, my English is still poor :)
All the best, have a nice day!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 10:00 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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." :)
>
> ---------------------------------------------------------------------
> 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
Re: [chain][v2] clever context
Posted by Matt Benson <gu...@gmail.com>.
On Sun, Sep 4, 2011 at 3:00 PM, James Carman <ja...@carmanconsulting.com> wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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." :)
Blame me for the misnomer, and feel free to correct any future uses of
it on my part. :P
Matt
>
> ---------------------------------------------------------------------
> 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
Hi Paul,
I tend to agree with you since I don't like the Map extension too, the
only concern is just to understand how strict backward compatibility
we want to keep, or if we want almost "redesign" the public APIs.
It is an important choose we have to made in a VOTE, I suggest to
promote first the branch in trunk and then understanding if breaking
the compatibility or not.
Thanks for your hints, much more than appreciated!
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Sep 5, 2011 at 5:54 AM, Paul Benedict <pb...@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 <ro...@fastmail.fm> wrote:
>> On 09/04/2011 04:00 PM, James Carman wrote:
>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
I honestly still haven't figured out how our Context should look
alike, better if I go sleep (it's almost midnight here in Italy :P)
and thinking about it :)
Good night, I'll come back writing tomorrow!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 9, 2011 at 11:32 PM, Paul Benedict <pb...@apache.org> wrote:
> Definitely interesting. I think this might be a special case though;
> ClassToInstanceMap is dedicated to class instances which is probably
> why they extended Map so that it has extra guarantees. I don't know if
> such a pattern is advisable for a regular key/value pair. What are
> your thoughts?
>
> On Fri, Sep 9, 2011 at 4:14 PM, Simone Tripodi <si...@apache.org> wrote:
>> indeed, the retrieve method would allow users assigning retrieved
>> object to all T that extend V, like the ClassToInstanceMap, take a
>> look at the method signatures[1]
>>
>> [1] http://s.apache.org/Mno
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict <pb...@apache.org> wrote:
>>> The purpose of Generics is to provide type safety with the implicit
>>> casts. Implicit casts because of typing shouldn't cause a
>>> ClassCastException. That would break an important principle behind
>>> using gnerics. Are you sure Guava is doing what you're proposing?
>>> Typing should always be safe; I would be surprised if they would allow
>>> unsafe implicit casts.
>>>
>>> On Fri, Sep 9, 2011 at 3:34 PM, Simone Tripodi <si...@apache.org> wrote:
>>>> 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 <pb...@apache.org> wrote:
>>>>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <el...@zupancic.name> wrote:
>>>>>> Specifying Object for V would be the most likely use case.
>>>>>>
>>>>>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
>>>>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
Definitely interesting. I think this might be a special case though;
ClassToInstanceMap is dedicated to class instances which is probably
why they extended Map so that it has extra guarantees. I don't know if
such a pattern is advisable for a regular key/value pair. What are
your thoughts?
On Fri, Sep 9, 2011 at 4:14 PM, Simone Tripodi <si...@apache.org> wrote:
> indeed, the retrieve method would allow users assigning retrieved
> object to all T that extend V, like the ClassToInstanceMap, take a
> look at the method signatures[1]
>
> [1] http://s.apache.org/Mno
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict <pb...@apache.org> wrote:
>> The purpose of Generics is to provide type safety with the implicit
>> casts. Implicit casts because of typing shouldn't cause a
>> ClassCastException. That would break an important principle behind
>> using gnerics. Are you sure Guava is doing what you're proposing?
>> Typing should always be safe; I would be surprised if they would allow
>> unsafe implicit casts.
>>
>> On Fri, Sep 9, 2011 at 3:34 PM, Simone Tripodi <si...@apache.org> wrote:
>>> 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 <pb...@apache.org> wrote:
>>>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <el...@zupancic.name> wrote:
>>>>> Specifying Object for V would be the most likely use case.
>>>>>
>>>>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
>>>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
indeed, the retrieve method would allow users assigning retrieved
object to all T that extend V, like the ClassToInstanceMap, take a
look at the method signatures[1]
[1] http://s.apache.org/Mno
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict <pb...@apache.org> wrote:
> The purpose of Generics is to provide type safety with the implicit
> casts. Implicit casts because of typing shouldn't cause a
> ClassCastException. That would break an important principle behind
> using gnerics. Are you sure Guava is doing what you're proposing?
> Typing should always be safe; I would be surprised if they would allow
> unsafe implicit casts.
>
> On Fri, Sep 9, 2011 at 3:34 PM, Simone Tripodi <si...@apache.org> wrote:
>> 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 <pb...@apache.org> wrote:
>>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <el...@zupancic.name> wrote:
>>>> Specifying Object for V would be the most likely use case.
>>>>
>>>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
>>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
The purpose of Generics is to provide type safety with the implicit
casts. Implicit casts because of typing shouldn't cause a
ClassCastException. That would break an important principle behind
using gnerics. Are you sure Guava is doing what you're proposing?
Typing should always be safe; I would be surprised if they would allow
unsafe implicit casts.
On Fri, Sep 9, 2011 at 3:34 PM, Simone Tripodi <si...@apache.org> wrote:
> 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 <pb...@apache.org> wrote:
>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <el...@zupancic.name> wrote:
>>> Specifying Object for V would be the most likely use case.
>>>
>>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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 <pb...@apache.org> wrote:
> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <el...@zupancic.name> wrote:
>> Specifying Object for V would be the most likely use case.
>>
>> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <el...@zupancic.name> wrote:
> Specifying Object for V would be the most likely use case.
>
> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain][v2] clever context
Posted by Elijah Zupancic <el...@zupancic.name>.
Specifying Object for V would be the most likely use case.
On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict <pb...@apache.org> wrote:
> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi <si...@apache.org> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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 <pb...@apache.org> 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 <si...@apache.org> 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 <el...@zupancic.name> wrote:
>>> Paul,
>>>
>>> You may be right. Which one is more idiomatic?
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <pb...@apache.org> wrote:
>>>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <el...@zupancic.name> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
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 <si...@apache.org> 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 <el...@zupancic.name> wrote:
>> Paul,
>>
>> You may be right. Which one is more idiomatic?
>>
>> Thanks,
>> -Elijah
>>
>> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <pb...@apache.org> wrote:
>>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <el...@zupancic.name> 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: 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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 <el...@zupancic.name> wrote:
> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <pb...@apache.org> wrote:
>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <el...@zupancic.name> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
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 <el...@zupancic.name> wrote:
> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <pb...@apache.org> wrote:
>> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <el...@zupancic.name> 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: 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
Re: [chain][v2] clever context
Posted by Elijah Zupancic <el...@zupancic.name>.
Paul,
You may be right. Which one is more idiomatic?
Thanks,
-Elijah
On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict <pb...@apache.org> wrote:
> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <el...@zupancic.name> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic <el...@zupancic.name> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain][v2] clever context
Posted by Elijah Zupancic <el...@zupancic.name>.
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
<ni...@gmail.com> wrote:
> On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic <el...@zupancic.name> 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
>> <ni...@gmail.com> wrote:
>>> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <si...@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
>>>> <ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic <el...@zupancic.name> 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
> <ni...@gmail.com> wrote:
>> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <si...@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
>>> <ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Elijah Zupancic <el...@zupancic.name>.
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
<ni...@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <si...@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
>> <ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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
<ni...@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <si...@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
>> <ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi <si...@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
> <ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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
<ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Elijah Zupancic <el...@zupancic.name>.
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
<ni...@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 <pb...@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 <ro...@fastmail.fm> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Niall Pemberton <ni...@gmail.com>.
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 <pb...@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 <ro...@fastmail.fm> wrote:
>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by James Carman <ja...@carmanconsulting.com>.
Well, if you're going to a 2.x, then I say break it and do it the
right way. Consider that my +1.
On Mon, Sep 5, 2011 at 8:51 AM, Simone Tripodi <si...@apache.org> 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/
>
>
>
> On Mon, Sep 5, 2011 at 1: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.
>>
>> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <pb...@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 <ro...@fastmail.fm> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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 <pb...@apache.org> 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 <ro...@fastmail.fm> 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: 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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
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 <ro...@fastmail.fm> 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: 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
Re: [chain][v2] clever context
Posted by Raman Gupta <ro...@fastmail.fm>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
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/
On Mon, Sep 5, 2011 at 1: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.
>
> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <pb...@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 <ro...@fastmail.fm> wrote:
>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by James Carman <ja...@carmanconsulting.com>.
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.
On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <pb...@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 <ro...@fastmail.fm> wrote:
>> On 09/04/2011 04:00 PM, James Carman wrote:
>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Paul Benedict <pb...@apache.org>.
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 <ro...@fastmail.fm> wrote:
> On 09/04/2011 04:00 PM, James Carman wrote:
>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by Raman Gupta <ro...@fastmail.fm>.
On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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
Re: [chain][v2] clever context
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <si...@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." :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
Hi Raman,
What you wrote is not 100% right, since Context *extends Map<String,
Object>*, so a correct assignment would be:
Context context = new MyContextImpl();
Context is able to store object identified by a key; let's assume you
store there your DataSource:
DataSource dataSource = ... ;
...
context.put("datasource", dataSource);
That needs to be retrieved in a Command during the chain execution;
the difference is by invoking `get`
Object obj = context.get("datasource");
DataSource dataSource = (DataSource) obj;
And `retrieve`
DataSource dataSource = context.retrieve("datasource");
That is able to 'auto-cast' the retrieved object while Map#get() not.
HTH, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 9:31 PM, Raman Gupta <ro...@fastmail.fm> wrote:
> On 09/04/2011 05:22 AM, Simone Tripodi wrote:
>> Hi all guys,
>> I think that generics could help us on improving the Context class;
>> I'm not particularly happy having it extending Map - it is needed
>> anyway for backward compatibility - but it is clear that Context is a
>> place where storing/retrieving objects identified by a key.
>> I propose adding two helper methods
>>
>> /** @since 2.0 */
>> <T> T retrieve( String key );
>>
>> /** @since 2.0 */
>> <T> void store( String key, T object );
>>
>> that would help users avoid the redundant code of type cast/checking
>> when assignments are already known (it throws a ClassCastException if
>> types are not assignable).
>> At the same time, old pattern is supported, users can choose their
>> preferred way to go, depending on their needs.
>> WDYT?
>
> Just curious -- what is the advantage of these two new methods over using:
>
> Context<String,Object> context = ...
>
> context.get(k);
> context.put(k, v);
>
> 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
Re: [chain][v2] clever context
Posted by Raman Gupta <ro...@fastmail.fm>.
On 09/04/2011 05:22 AM, Simone Tripodi wrote:
> Hi all guys,
> I think that generics could help us on improving the Context class;
> I'm not particularly happy having it extending Map - it is needed
> anyway for backward compatibility - but it is clear that Context is a
> place where storing/retrieving objects identified by a key.
> I propose adding two helper methods
>
> /** @since 2.0 */
> <T> T retrieve( String key );
>
> /** @since 2.0 */
> <T> void store( String key, T object );
>
> that would help users avoid the redundant code of type cast/checking
> when assignments are already known (it throws a ClassCastException if
> types are not assignable).
> At the same time, old pattern is supported, users can choose their
> preferred way to go, depending on their needs.
> WDYT?
Just curious -- what is the advantage of these two new methods over using:
Context<String,Object> context = ...
context.get(k);
context.put(k, v);
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
Hi added that feature, see CHAIN-56 for details.
I'll re-upload the site on my p.a.o home so we can continue discussing
about [chain] potential graduation.
Thanks, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 6:26 PM, Simone Tripodi <si...@apache.org> wrote:
> Hi James!
> I remember that thread :(
> Hope you have a nice WE, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Sep 4, 2011 at 2:39 PM, James Carman <ja...@carmanconsulting.com> wrote:
>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>> and it was shot down
>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>> Good luck with that. It wasn't worth my time to continue to argue
>> about it anymore, so I reverted it.
>>
>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
>>> Hi all guys,
>>> I think that generics could help us on improving the Context class;
>>> I'm not particularly happy having it extending Map - it is needed
>>> anyway for backward compatibility - but it is clear that Context is a
>>> place where storing/retrieving objects identified by a key.
>>> I propose adding two helper methods
>>>
>>> /** @since 2.0 */
>>> <T> T retrieve( String key );
>>>
>>> /** @since 2.0 */
>>> <T> void store( String key, T object );
>>>
>>> that would help users avoid the redundant code of type cast/checking
>>> when assignments are already known (it throws a ClassCastException if
>>> types are not assignable).
>>> At the same time, old pattern is supported, users can choose their
>>> preferred way to go, depending on their needs.
>>> WDYT?
>>> Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
Hi James!
I remember that thread :(
Hope you have a nice WE, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 2:39 PM, James Carman <ja...@carmanconsulting.com> wrote:
> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
> Good luck with that. It wasn't worth my time to continue to argue
> about it anymore, so I reverted it.
>
> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
>> Hi all guys,
>> I think that generics could help us on improving the Context class;
>> I'm not particularly happy having it extending Map - it is needed
>> anyway for backward compatibility - but it is clear that Context is a
>> place where storing/retrieving objects identified by a key.
>> I propose adding two helper methods
>>
>> /** @since 2.0 */
>> <T> T retrieve( String key );
>>
>> /** @since 2.0 */
>> <T> void store( String key, T object );
>>
>> that would help users avoid the redundant code of type cast/checking
>> when assignments are already known (it throws a ClassCastException if
>> types are not assignable).
>> At the same time, old pattern is supported, users can choose their
>> preferred way to go, depending on their needs.
>> WDYT?
>> Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
Couldn't find better words, big +1 to your words James!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 7:30 PM, James Carman <ja...@carmanconsulting.com> wrote:
> To be clear, I am also in favor of this approach. I don't think we
> need to patronize our users by trying to hold their hands. A
> ClassCastException would be a pretty obvious indicator as to what is
> going wrong with something like this.
>
> On Sun, Sep 4, 2011 at 12:13 PM, Matt Benson <gu...@gmail.com> wrote:
>> Obviously I've suggested this "auto-cast" or
>> whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
>> use.
>>
>> Matt
>>
>> On Sun, Sep 4, 2011 at 7:39 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>>> and it was shot down
>>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>>> Good luck with that. It wasn't worth my time to continue to argue
>>> about it anymore, so I reverted it.
>>>
>>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
>>>> Hi all guys,
>>>> I think that generics could help us on improving the Context class;
>>>> I'm not particularly happy having it extending Map - it is needed
>>>> anyway for backward compatibility - but it is clear that Context is a
>>>> place where storing/retrieving objects identified by a key.
>>>> I propose adding two helper methods
>>>>
>>>> /** @since 2.0 */
>>>> <T> T retrieve( String key );
>>>>
>>>> /** @since 2.0 */
>>>> <T> void store( String key, T object );
>>>>
>>>> that would help users avoid the redundant code of type cast/checking
>>>> when assignments are already known (it throws a ClassCastException if
>>>> types are not assignable).
>>>> At the same time, old pattern is supported, users can choose their
>>>> preferred way to go, depending on their needs.
>>>> WDYT?
>>>> Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by James Carman <ja...@carmanconsulting.com>.
To be clear, I am also in favor of this approach. I don't think we
need to patronize our users by trying to hold their hands. A
ClassCastException would be a pretty obvious indicator as to what is
going wrong with something like this.
On Sun, Sep 4, 2011 at 12:13 PM, Matt Benson <gu...@gmail.com> wrote:
> Obviously I've suggested this "auto-cast" or
> whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
> use.
>
> Matt
>
> On Sun, Sep 4, 2011 at 7:39 AM, James Carman <ja...@carmanconsulting.com> wrote:
>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>> and it was shot down
>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>> Good luck with that. It wasn't worth my time to continue to argue
>> about it anymore, so I reverted it.
>>
>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
>>> Hi all guys,
>>> I think that generics could help us on improving the Context class;
>>> I'm not particularly happy having it extending Map - it is needed
>>> anyway for backward compatibility - but it is clear that Context is a
>>> place where storing/retrieving objects identified by a key.
>>> I propose adding two helper methods
>>>
>>> /** @since 2.0 */
>>> <T> T retrieve( String key );
>>>
>>> /** @since 2.0 */
>>> <T> void store( String key, T object );
>>>
>>> that would help users avoid the redundant code of type cast/checking
>>> when assignments are already known (it throws a ClassCastException if
>>> types are not assignable).
>>> At the same time, old pattern is supported, users can choose their
>>> preferred way to go, depending on their needs.
>>> WDYT?
>>> Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by Simone Tripodi <si...@apache.org>.
Hi Matt!
indeed, that's thanks to you that the Digester3 has this feature!!! :)
Thanks for the feedback!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 6:13 PM, Matt Benson <gu...@gmail.com> wrote:
> Obviously I've suggested this "auto-cast" or
> whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
> use.
>
> Matt
>
> On Sun, Sep 4, 2011 at 7:39 AM, James Carman <ja...@carmanconsulting.com> wrote:
>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>> and it was shot down
>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>> Good luck with that. It wasn't worth my time to continue to argue
>> about it anymore, so I reverted it.
>>
>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
>>> Hi all guys,
>>> I think that generics could help us on improving the Context class;
>>> I'm not particularly happy having it extending Map - it is needed
>>> anyway for backward compatibility - but it is clear that Context is a
>>> place where storing/retrieving objects identified by a key.
>>> I propose adding two helper methods
>>>
>>> /** @since 2.0 */
>>> <T> T retrieve( String key );
>>>
>>> /** @since 2.0 */
>>> <T> void store( String key, T object );
>>>
>>> that would help users avoid the redundant code of type cast/checking
>>> when assignments are already known (it throws a ClassCastException if
>>> types are not assignable).
>>> At the same time, old pattern is supported, users can choose their
>>> preferred way to go, depending on their needs.
>>> WDYT?
>>> Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by Matt Benson <gu...@gmail.com>.
Obviously I've suggested this "auto-cast" or
whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
use.
Matt
On Sun, Sep 4, 2011 at 7:39 AM, James Carman <ja...@carmanconsulting.com> wrote:
> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
> Good luck with that. It wasn't worth my time to continue to argue
> about it anymore, so I reverted it.
>
> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
>> Hi all guys,
>> I think that generics could help us on improving the Context class;
>> I'm not particularly happy having it extending Map - it is needed
>> anyway for backward compatibility - but it is clear that Context is a
>> place where storing/retrieving objects identified by a key.
>> I propose adding two helper methods
>>
>> /** @since 2.0 */
>> <T> T retrieve( String key );
>>
>> /** @since 2.0 */
>> <T> void store( String key, T object );
>>
>> that would help users avoid the redundant code of type cast/checking
>> when assignments are already known (it throws a ClassCastException if
>> types are not assignable).
>> At the same time, old pattern is supported, users can choose their
>> preferred way to go, depending on their needs.
>> WDYT?
>> Many thanks in advance, 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
Re: [chain][v2] clever context
Posted by James Carman <ja...@carmanconsulting.com>.
Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
and it was shot down
(http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
Good luck with that. It wasn't worth my time to continue to argue
about it anymore, so I reverted it.
On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <si...@apache.org> wrote:
> Hi all guys,
> I think that generics could help us on improving the Context class;
> I'm not particularly happy having it extending Map - it is needed
> anyway for backward compatibility - but it is clear that Context is a
> place where storing/retrieving objects identified by a key.
> I propose adding two helper methods
>
> /** @since 2.0 */
> <T> T retrieve( String key );
>
> /** @since 2.0 */
> <T> void store( String key, T object );
>
> that would help users avoid the redundant code of type cast/checking
> when assignments are already known (it throws a ClassCastException if
> types are not assignable).
> At the same time, old pattern is supported, users can choose their
> preferred way to go, depending on their needs.
> WDYT?
> Many thanks in advance, 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