[zak_mc_kracken]

If you need reification, then you are doing a runtime look up of type information.

Which, by definition, has nothing to do with generic types.

By the way, this is another reason why erasure is the only sane way of doing this: supporting reification means that you let developers second guess what the compiler already proved for you. Just say no to reification.

[useerup]

What? No, I need reification because:

1) I do not want the compiler to create extraneous call-site code, bridge methods and other cruft to ensure that a value is really of the declared type (or derived from it). For instance, when you iterate over a (generic) collection, the compiler will insert type checks and downcasts in to the call site code. With reification the collection would be guaranteed type-safe and no extra cruft with incurred overhead needed.

2) Type erasure rules out using primitive types (or value types) as generic type parameters. Reification allows the actual type to be used with generics, regardless of the "kind".

3) Type erasure forces me into the underworld of automatic boxing/unboxing conversions and suboptimal code. Reified generics allows the compiler to generate verify the code at compile time but generate actual optimized (with respect to the type) code when JITting.

4) Type erasure has a large number of contra-intuitive consequences, gotchas. Example: All realizations share the static members, even though they should be separate classes. Type erasure resembles a macro scheme rather than a function that return classes.

There's much more. You are actually the first person I have ever encountered who argue that type erasure is desirable. I can understand type erasure from a compatibility point of view, but I have never seen anyone defending type erasure without the referring to the migration compatibility that was achieved with TE. That includes Neal Gafter, one of the main forces behind generics in Java.

[Devthrowaway80]

What you wrote is pretty much my point of view, so I'm not going to elaborate. :) Type erasure also hobbled the type system in Scala, annoyingly.

Type erasure was a compromise to allow migration, it is not a design choice that would've been made otherwise.

[lomnakkus]

Type erasure is the very reason that Scala could adopt a more advanced type system. Otherwise it would be absolutely forced to essentially conform exactly to Java's type system since the targeted bytecode would require all sorts of type annotations which would have to be correct-according-to-java.

Scala wouldn't even be possible in its current form if Java had used reified generics.

(Scala type's system is constrained by the need for interop with Java, but that's an unrelated issue.)

[useerup]

> Type erasure is the very reason that Scala could adopt a more advanced type system.

No. Having a byte-code interpreter which is essentially an assembly language allows you to create any type system you want. It is wwhen you require interop with an existing type system that you are constrained.

>Otherwise it would be absolutely forced to essentially conform exactly to Java's type system since the targeted bytecode would require all sorts of type annotations which would have to be correct-according-to-java.

One could argue that it would be prudent to base your type system on the type system of the platform you choose. Essentially what Scala chose the route of not integrating deeply with the platform type system. That choice could have been made regardless of how advanced the type system of the platform was.

So if the platform had offered reified generics, Scala could still had chosen to ignore those and gone with type erasure. But they could also have chosen to support reified generics. I'm interested in what concrete constraints that would have imposed on Scalas type system, except for interop with Java.

Ironically, the chosen design has forced Scala into adorning with all sorts of type annotations to ease interop with Java: It has to lie about the generic type argument the same way Java does in the type metadata, i.e. "consider is a collection of Shapes. Note: it may be other object types so you must perform downcasts yourself*".

[lomnakkus]

> No. Having a byte-code interpreter which is essentially an assembly language allows you to create any type system you want. It is wwhen you require interop with an existing type system that you are constrained.

Not with anywhere near decent performance.

[lomnakkus]

#1: The JIT can optimize this out in many cases.

#2: No it doesn't. You can still specialize as appropriate when you know the types at compile time, see e.g. miniboxing for Scala.

#3: This was added by the Java language designers for convenience. It would be possible to require explicit casting/specialization, but they deemed it too verbose. Of course then we ended up with advice like "explicitly unbox" as seen in Effective Java...

The last bit is an appeal to authority. There are many people, esp. in the Scala community, who argue convincingly against reification.

[useerup]

> The JIT can optimize this out in many cases.

It can optimize some of the cases. Problem persists and is now even less predictable.

> No it doesn't. You can still specialize as appropriate when you know the types at compile time, see e.g. miniboxing for Scala.

Yes it does. The subject here is generics in Java, not scala kludges to compensate for the poor generics design.

> This was added by the Java language designers for convenience.

Strawman. You can point to any language feature and call it convenience, basically anything above a Turing Machine is convenience. The fact is that they realized that the type erased generics would appear severely hampered if they could not be used for the most used types at all. Hence, they swept the problem under the rug, by allowing implicit (automatic) conversions. The problem is still there, there's a big bulge on the rug and the linked FAQ is essentially a map to guide you around it so that you do not trip.

> The last bit is an appeal to authority. There are many people, esp. in the Scala community, who argue convincingly against reification

I'd be interested in hearing those arguments, specifically those that do not invoke interoperability with Java. Have source?

My source: http://gafter.blogspot.dk/2004/09/puzzling-through-erasure-a...