nested generic HashMap problem
in [Java Programming]
|
Prev: Quartz with Spring: more jobs with different input argument
Next: call jni function dynamically without getting a JNIEnv handle as an argument.
From: Daniel Pitts on 27 Apr 2010 15:51 On 4/27/2010 7:39 AM, 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, the problem is "T" is different for every key of the map. map.put(String.class, new Map<Long, String>()); map.put(Foo.class, new Map<Long, Foo>()); There is no definition for Map<Class<...>, ...> which will fit the above usecases. One will need to carefully ensure the key matches the value, and cast appropriately, or not use a java.util.Map. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Daniel Pitts on 27 Apr 2010 15:52 On 4/27/2010 12:02 PM, 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. >> > > 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. It has been the problem that the OP has been trying to solve this entire thread. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Lew on 27 Apr 2010 19:16 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>. Lew wrote: >> That isn't what you asked for in the post to which I replied. Daniel Pitts wrote: > It has been the problem that the OP has been trying to solve this entire > thread. In which he referred to wildcarded generics. In the post to which I responded, he seemed to have changed tack and remarked on what on the surface was a very specific point. While true, Daniel, your point is irrelevant. I believe that what the OP is doing is best served by finding some upper-bound type for the keys, at least, of the primary and secondary map layers, and using it for T, perhaps making the secondary value simply 'Object'. What they're trying to do is never going to be painless. Their desire to have the structures be typeless dooms them to conflict with the heart of generics. They will have to cast somewhere. Fortunately, they have a class token buried in all that goop, so they can at least hide the 'catch (ClassCastException ex)' blocks down in the depths and throw only runtime exceptions. They'll need to Javadoc the hell out of the structures so that everyone knows that everything has to match the class token. As I finished typing this I see your other post, Daniel, where you made many of these points as well. -- Lew
From: Arne Vajhøj on 27 Apr 2010 19:41
On 27-04-2010 15:17, Daniel Pitts wrote: > 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. +1 Arne |