Ugly as heck, sure, but it works fine (for example, most of the generics-extended methods return a 'Type' which is little more than a flag interface - ironically, in order to do generics introspection, a device designed to avoid casts and instanceof checks, you need to litter your code with casts and instanceof checks!)
For example, in an xml parser I wrote before I learned that there's such a thing as jaxb, I look at the generics part of a collection class to figure out how to parse the tags in a block of xml. This is a much nicer solution that forcing you to disregard the DRY principle and add an annotation. I admit thats the only time I really -needed- the feature to make something look good and work well, but in that one instance, I had no problems. Other than a block of somewhat ugly code. On Nov 6, 10:53 am, Casper Bang <[EMAIL PROTECTED]> wrote: > It's actually all described in chapter 7.5 of "Java Generics and > Collections" which the Posse have endorsed in the past. Basically you > can introspect it (look for ParameterizedType) and it can help you in > a few instances, but in my humble experiences those solutions often > turns ugly and fragile (played with that a while > ago:http://coffeecokeandcode.blogspot.com/2008/05/type-strategy-pattern.html). > > /Casper > > On Nov 6, 3:13 pm, Jess Holle <[EMAIL PROTECTED]> wrote: > > > Viktor Klang wrote: > > > On Thu, Nov 6, 2008 at 1:49 PM, Jess Holle <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Viktor Klang wrote: > > >> Actually guys, referential equality is kind of retarded, so the > > > >> Map<String,Integer>.class == Map<Foo,Bar>.class > > > >> example is bad. > > > >> However, > > > >> Map<String,Integer>.class.equals(Map<Foo,Bar>.class) SHOULD > > >> return false > > > No, it MUST not -- else loads of things break. > > > > If you want to make an omelet, you've got to break some eggs... > > > Yes, but breaking eggs just cause you feel like it is for toddlers, not > > chefs. > > > > Further == and .equals MUST give the same results for Class > > > objects -- else loads of things break. > > > > The "ConcreteClass" noted below would not be a Class -- it would > > > be a new API. > > > > Yeah, I realize that, that's why I'm moving away from Java. > > > I'm still missing what the real benefit to having these Class objects be > > unequal is. It sounds nice in some ivory tower sort of way, but really > > as long as you have access to the fact that the "K" parameter is String > > and the "V" parameter is Integer (and the compiler can use this as well > > to do things like "new V[]"), I don't really see any issue. > > > -- > > Jess Holle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
