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 <pbened...@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 <simonetrip...@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 <pbened...@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 <simonetrip...@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 <pbened...@apache.org> >>>> wrote: >>>>> On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic <eli...@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 <pbened...@apache.org> >>>>>> wrote: >>>>>>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi >>>>>>> <simonetrip...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
