Prev: Quartz with Spring: more jobs with different input argument
Next: call jni function dynamically without getting a JNIEnv handle as an argument.
From: Lew on 27 Apr 2010 10:39 Chris Riesbeck wrote: > I don't follow the "don't have a type" part here. The correlation I was > trying to capture was > > T get(Demo<T>, long) > > using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be > well-defined, just not definable in Java. > What do you mean, not definable? That's exactly how you define it, what you wrote just there, modulo the typos. class Registry <T> { private final Map <Demo <T>, Map <Long, T>> demoMaps = new HashMap <Demo <T>, Map <Long, T>> (); ... } -- Lew
From: markspace on 27 Apr 2010 11:16 Chris Riesbeck wrote: > I don't follow the "don't have a type" part here. The correlation I was > trying to capture was > > T get(Demo<T>, long) > > using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be > well-defined, just not definable in Java. What I was referring to was the actual type used in the program. Cache doesn't have a type (parameter) and so the hash map doesn't either. Thus, Java says "I don't have a type to check here" when you try to return a value. private HashMap<Class<?>, HashMap<Long, ?>> maps = new HashMap<Class<?>, HashMap<Long, ?>>(); The ? says to me "I have no type." YMMV. In your design, you have a type, yes, but you need to tell the compiler.
From: Chris Riesbeck on 27 Apr 2010 14:29 Lew wrote: > Chris Riesbeck wrote: >> I don't follow the "don't have a type" part here. The correlation I was >> trying to capture was >> >> T get(Demo<T>, long) >> >> using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be >> well-defined, just not definable in Java. >> > > What do you mean, not definable? That's exactly how you define it, > what you wrote just there, modulo the typos. > > class Registry <T> > { > private final Map <Demo <T>, Map <Long, T>> demoMaps = > new HashMap <Demo <T>, Map <Long, T>> (); > > ... > } > > -- > Lew That defines a Map of Maps of one type T. I.e., you can make one Registry where an instance of Demo<Book> retrieves a Map of type <Long, Book>, and another Registry where a key of type Demo<Author> retrieves a Map of type <Long, Author>. But you can't define a single Registry where a Demo<Book> retrieves a Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.
From: Lew on 27 Apr 2010 15:02 Chris Riesbeck wrote: >>> I don't follow the "don't have a type" part here. The correlation I was >>> trying to capture was >>> >>> T get(Demo<T>, long) >>> >>> using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be >>> well-defined, just not definable in Java. > Lew wrote: >> What do you mean, not definable? That's exactly how you define it, >> what you wrote just there, modulo the typos. >> >> class Registry <T> >> { >> private final Map <Demo <T>, Map <Long, T>> demoMaps = >> new HashMap <Demo <T>, Map <Long, T>> (); >> >> ... >> } > >> -- >> Lew > Don't quote sigs. Chris Riesbeck wrote: > That defines a Map of Maps of one type T. I.e., you can make one > Registry where an instance of Demo<Book> retrieves a Map of type <Long, > Book>, and another Registry where a key of type Demo<Author> retrieves a > Map of type <Long, Author>. > > But you can't define a single Registry where a Demo<Book> retrieves a > Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>. > That isn't what you asked for in the post to which I replied. -- Lew don't quote sigs
From: Daniel Pitts on 27 Apr 2010 15:17
On 4/27/2010 3:33 AM, Lew wrote: > Daniel Pitts wrote: >>> As a side note, I would make base and cache final. > > Chris Riesbeck wrote: >> I agree. It's a habit I still haven't gotten into, even though I const >> like crazy in C++. > > The semantics of Java's 'final' differ from C++'s 'const' somewhat, as > with so many things that are similar between the languages but not quite > the same. > Yes, I miss C++ "const", actually. I hated it when I was first learning C++, because it stopped me from doing things I thought I should be able to do (but were actually bad to do). -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> |