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
