The generics design team was very much aware of the usefulness of
reification, but did not see a way to add it without seriously
breaking backwards compatibility. Java 1.5 already came with a giant
bag of changes, and it was at some point dropped in favour of type
erasure. I haven't looked too closely at it, but I know there's a
supposedly quite complete proposal out there to add it at some point.
Many generics whines are not actually fixed by reification (In other
words, the usual retort to 'whine, whine, generics is HARD! whine!'
being 'if only they were reified' without knowing what the heck you're
talking about, is a bad idea. Makes you look bad - many generics
issues arise simply from the fact that co/contravariance is just plain
hard, period. It's hard in scala, too, and that has reification).
However, a few useful things are certainly addressed by reification:
1. You can't just new up a T, because there's no way in java right now
to specify constructors in a type spec. However, you *CAN* get at T's
class (T.class, probably), and from there you can either use
newInstance(), or have a closer look at the constructors that T has,
and make one from there.
2. A T[] is not an Object[] and I have no idea where you got that
impression. The actual underlying array type of a T[] depends a lot on
where the T came from. For example, if an array was passed in and the
T was derived from it, the array will actually have the right type (if
T = String, the array is String[]). In other circumstances, the
array's type is of the lower bound of the T - if you didn't specify
one, that would indeed be Object[]. However, arrays are *FUNDAMENTALLY
BROKEN*. And they will not be fixed. Arrays do not properly adhere to
the rules of co and contravariance, and reification can't do anything
to change this. Any attempt to mix and match arrays and generics,
reification or not, is going to fail. And the blame lies solely with
arrays. Stop using arrays. Consider them deprecated, except for tight
loops where you can't deal with the overhead of a List - especially
for primitive list/arrays (a List<Integer> takes up waaay more space
and is quite a bit slower than an int[], and this might be relevant
for gfx code, for example).
Addendum: Note that, due to #2, the decision to have varargs produce
an array was, and there's no easy way to say this: Bone headed idiocy.
Reification might be a good excuse to fix the deplorable warnings that
arise when you stuff generics into a varargs list, though. I somewhat
doubt it's going to be an actual practical help. That's fortunately
not too relevant, because the current state of the generics/varargs
mix warning is that the warning is essentially a bug in javac which
for some reason sun is unwilling or incapable of understanding.
3. erasure occurs in three separate places in generics:
Generics information on types is NEVER ERASED (so in public class Foo
{ List<String> list = null; }, the Generics is now and has always been
reified).
Generics information on objects is ALWAYS ERASED (so in new
ArrayList<String>();, the generics info is stripped). This would be
fixed with reification.
Generics information on signatures is NOT SIGNIFICANT, but not erased
either. Reification will not fix this. So, the following code doesn't
work now, never has worked, and will never work in the future even if
reification is ever added:
public void method(List<String> list) {}
public void method(List<Integer> list) {}
Generics information on method calls is ALWAYS ERASED (so when
calling a method and either using inference or an explicit generics
set in html brackets, the generics info is not actually there to look
at for the method that is being called). This might, or might not, be
fixed, and it's not quite the same as generics info on objects. For
example, with an object you can call a method on it (.getType(),
perhaps), but what would you do to get at the actual type of 'R' for a
call to this method:
public static <R> List<R> emptyList() {
return EMPTY_LIST;
}
I haven't looked closely at the proposal to add reification, but I
doubt there will be a way to ascertain it.
On Jan 28, 2:39 am, Christian Catchpole <[email protected]>
wrote:
> Fair enough - if reification can be seamlessly added then I shall in
> fact insert a sock within it. (That's got to be better than the Dick
> Wall - unless they are some how related).
>
> Do you think it was an under-sight that they didn't expect people to
> want reification? Or perhaps they were aware of it but left it in the
> 'in' tray.
>
> Do you know if reification will solve new T() - and the fact that a T
> [] is actually a Object[] - and will it break the current hack of
> simply casting a new Object[].
>
> I'm not being facetious. These are serious questions. :)
>
> On Jan 28, 10:23 am, Reinier Zwitserloot <[email protected]> wrote:
>
> > They didn't bollocks up generics at all. They are fine as is.
>
> > Reification would be great, but fortunately there is absolutely
> > nothing in the current implementation that precludes reification. In
> > other words, reification is -really- hard, but nothing that was done
> > so far made it harder. Anyone wanna name a way that would have been
> > better? If you don't have anything, then with all due respect, put a
> > sock in it.
>
> > As far as closures go - just give me a month. I'm working on a uniting
> > proposal that should make everyone happy. At least, everyone that
> > likes one of the many closure proposals out there. Especially now that
> > BGGA is effectively out on its arse due to Gafter leaving and the
> > other letters in BGGA stopped caring long ago. The prototype's last
> > commit was 5 months ago, and it still doesn't properly do long returns/
> > breaks/continues, one of the two main reasons why BGGA exists in the
> > first place. Even though it looks like the closure horse has been well
> > beaten to death, I actually think its still for a lack of leadership
> > that there's no consensus.
>
> > On Jan 28, 12:22 am, Christian Catchpole <[email protected]>
> > wrote:
>
> > > Hey I didn't say we don't want closures. I'm just saying, for Java's
> > > sake, "Closures, close thy self". :)
>
> > > Maybe after bollocksing up generics, they are being super cautious.
>
> > > On Jan 28, 12:33 am, Hairless_ape <[email protected]> wrote:
>
> > > > We need to add something to Java. Closures is something, therefore we
> > > > must add closures to Java.
>
> > > > Stop this destructive line of thought against closures or you will get
> > > > 5 days in the Dick Wall room.
> > > > (Oh and references to the Dick Wall room will NEVER get old)
>
> > > > On Jan 27, 10:47 am, Christian Catchpole <[email protected]>
> > > > wrote:
>
> > > > > How much resource (inside and outside of Sun) has been expended going
> > > > > over and over the multiple options for closures? I fear there is no
> > > > > balance to the force. *
>
> > > > > * And here I was thinking I would never make a geeky star wars
> > > > > reference.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
