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
-~----------~----~----~----~------~----~------~--~---

Reply via email to