In retrospect... what is the vote now?

Question

Generics are evil!
If you are into history, here's a two year old thread, from which nothing I have seen has changed the basic concern of mine...
http://forum.java.sun.com/thread.jspa?threadID=417410&start=0&tstart=0
Wonder what the consensus is now?
best, etc.

Answer 1

Which means you can guarantee the type will becompatible with the derived type. Are you suggesting
that because you don't think they are that useful is
a good reason to not have them? A lot of designs can
use them and use them well.
If a selftype is delcared in a field or as a method
parameter, the only valid compadible assignment to
that type would be this (or some value returned by a
self type) since you would not know what your actual
implementing class is.
I simply do not see how you can get new instances of
this's class without using clone.I don't know why you assume that self-types are only related to retuning things. Generic parameters are also used with method arguments and variables and parameters to members.
That seems to me to be an incredibly stupid thing todo. Generally, the first thing done with the
reference returned from clone is cast it to the type
of the Object that returned it. I can't imagine a
situation where I'd want Foo.clone() to return a Bar
where Bar isn't a subtype of Foo.
Ok, sure it is, but code currently can do it, so we
can't go back and change it.Why do you think having self-types would require us to change the signature of clone()?
Why even have arrays?To implement ArrayList. They are here now, and they
are here to stay, the way they are built make them
generic incompadible.
Did I give the impression that I didn't know whythis was the case?
Why did you bring it up then?I was answering a question about what the problems exist with generics. It was in this thread. You can read it if you are still not clear.
Some other solution. One that has true runtimesupport.
You are more likely to not need runtime support then
you would be. You can add in your own runtime support
if you really need to, but the current design adds no
overhead to code if it were generified.Wrong. There is runtime support in the current implementation that does add overhead. It's just not very useful.
Then my idea of how generics are not a complete
solution is quite a bit different from yours.
E.g.
1. Why is method only generified on the class it was
defined, and not on its parameters? Its that generic
parameters are fixed, you could declare a Method
class for invoking all methods with 1 parameter, but
you would need another class for 2 parameters.An interesting idea. It doesn't seem to be something many people are concerned with.
2. I would like a way to declare a method that takes
in an array with a speficied size.I guess you could frame that as generics. Interesting but not something I'm concerned about.
3. I want a method parameter that takes in a
Rectangle that will never change, or return a
Rectangle that does not change, sure I could declare
a class for a constant Rectangle, but I would need to
declare classes for every class I wanted to use like
that.This is definitely not generics. This is what most people who want the const keyword to be supported would like it to do. There are RFEs on this and have been since long before generics were developed.