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
