Hacker News Reader

Comment by mmebane | Hacker News Reader

I've often thought of C++'s templates (when used in the "straightforward" manner, anyway) as more of compile-time duck typing than a real generic type system. Even moving from C++ to Java took a while to get used to.

View on HN

Moving to Java generics took me a while mostly because of type erasure. In C++, I'm used to being able to use the type in a generic class or function, which kept biting me in Java.

What do you mean by use the type? Query for type metadata at runtime?

No, that's not what I meant, but yes, that is a limitation. (Just not one I hit.) The big one is not being able to allocate objects of that type. For example, in C++, I can say:

  template <class T>
  T* allocate() {
    return new T();
  }

That's not possible in Java because of type erasure. When you try something like that, you get an error message like:

  Erasure.java:12: error: unexpected type
              return new T();
                       ^
    required: class
    found:    type parameter T
    where T is a type-variable:
      T extends Object declared in class Foo

Again, this is because of type erasure: Foo<T> is really Foo<Object>, where Java just does a cast for you to T in all of the right places. It does not actually know the type. For me, that lead to all sort of contortions because a class Foo<T> could not allocate objects of type T internally. I needed to create factory methods in other places which Foo would call. In the instance I'm thinking of, those factory methods ended up living in derived classes.

C++ templates have its issues, but it allows parametric polymorphism. In Java, I could not write such code, which was what I was used to. Because of type erasure, I was forced more towards subtype polymorphism, even though I was implementing generic classes.

I'm not quite sure that's due to type erasure. What would happen to this code if T were an interface? Meanwhile even though (AFAIK) GHC uses type erasure, you can do something like that and create values "de novo" if the typeclass supports it e.g. Alternative's `empty` or MonadPlus's `mzero`

Even if you constrain the type to be something you know is a class, it won't work. [1]

The typical workaround in Java is to either pass around .class instances, or to do tricks with anonymous subclasses to create a type token. [2]

[1]: https://ideone.com/th18eh [2]: http://docs.guava-libraries.googlecode.com/git/javadoc/com/g...

> Even if you constrain the type to be something you know is a class, it won't work. [1]

Oh yes, I'm not saying it's possible to do this in Java, AFAIK you're right that it's not, I'm saying I'm not sure it's because of type erasure, at least type erasure on its own.

I think it is. As far as Java is concerned, T is Object in that context. It can't generate code for "allocate a T" because Foo only actually operates on Objects, not Ts. That is, there will be one version of Foo, and that version will generate code to interact with Objects, not Ts. It can't allocate a T because the type of T is erased from Foo. That is type erasure.

Reply on news.ycombinator.com