On Jan 27, 7:34 pm, Christian Catchpole <christ...@catchpole.net>
wrote:
>
> When generics first came along I thought 'great, no more casting'. So
> I disassembled some source, only to find that casts still do exist
> after the caller calls a generified method. This is because generics
> can still be subverted with casts.
With the notable exception of C++, most language implementations with
parametric polymorphism implement it via some form of "casting" in the
generated code. The difference is that since languages like ML and
Haskell don't already have casting in the Java sense their
implementations can do their "casts" in the C like way of just
interpreting bit patterns differently without checking tags, thus the
cast isn't as visible in the generated code.
Java doesn't really have that option by the design goals of the JVM.
C++ is one of the very few languages that mandates parameteric
polymorphism via polyinstantiation (and, really, what it does isn't
paramteric polymorphism but a mostly type-focused macro scheme that
happens to look like parameteric polymorphism when you squint).
Polyinstantiation was an option for Java, but full polyinstantiation
is problematic with separate compilation. In Java land it would have
meant runtime code generation. Some optimizing compilers for Hasklell
and ML (eg JHC and MLTon respectively) implement using
polyinstantiation but sacrifice separate compilation as a result.
The .Net platform uses a limited form of runtime polyinstantiation to
deal with primitive type parameters (e.g. List<int> gets different IL
code than a List<String> on the .Net platform).
>
> (Now I would hope that the JIT could detect cases where subversion
> can't occur and remove the cast, but that's another story).
Yes, that's probably true. But even when it can't be optimized away a
JVM cast is pretty cheap - it's just a check of a tag on an object.
>
> My assumption was that generics is a 'caller side typecheck facade'.
> An ArrayList<String> is just an ArrayList with type checks on input
> and output. Hence my definition of 'bollocks'.
Like I say, that's true of most parametrically polymorphic languages,
except they don't necessarily do a runtime type check before
reinterpreting the bit pattern.
> But I have been known to be wrong about some things on rare occasion.
In this case I'd say you're slightly wrong in the sense that, once the
designers rejected C++ style polyinstantiation, casting was the only
real option.
--~--~---------~--~----~------------~-------~--~----~
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
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
