[chain][v2] clever context

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

Re: [chain][v2] clever context

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

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

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

123