Hacker News Reader

Comment by rusbus | Hacker News Reader

In Java, you can't make runtime decisions based on the generic type of an object. Eg. you can't have a List<?> and check to see if it's a List<Foo> or a List<Bar> -- that information has been erased.

You could look at the head of the list to make that determination, (because the List members still have a concrete type), but that isn't a general purpose solution.

Languages like Scala use manifests to preserve the information but it's a major kludge.

View on HN

Looking at the head of a List does not work. The class of that element is within the scope of <? extends ListType>, an is not necessarily not ListType.

*and is not necessarily ListType.

Idiot.

For the downvoters, the author is correcting themselves after the edit window. It's clearly self-deprecating humor, not a personal attack.

To spell this out so it's a bit more obvious, given a Thing at head of a list, you could have:

    - a List<Thing>
    - a List<ThingSuperclass>
    - a List<? extends Thing>
    - a List<? super ThingSubclass>
    - a List<IThing>
    - a List<ILiterallyAnyImplementedIFace>
    - a List<IHaventForgottenInterfacesCanExtendOthers>
    - a List<Object>
    - a List<I'm probably forgetting some possibilities>

And you have no way of knowing which it is.

So yes, it's a boundary, which is significantly more than nothing. But far less useful than it feels like at first.

Not to mention that an empty list still has a type...

One the way to looking at other things(tm) I found a blog post by a CS language researcher talking about type erasure.

His two points.

Being able to do type erasure is great because it means your language is coherent. (Don't need to do any nasty kluges in the run time)

And then everyone ratfucks themselves by actually implementing type erasure, and now your language will never have good tooling and thus will die a lonely unmourned death.

He commented that C/C++ has type erasure and it's also a massive kludge (via the elf format). No one will invest that much effort into a new language.

tl;dr: Type erasure, it's great, don't do it.

What tooling do you think is missing due to erasure?

Not a CS person, but I think if you keep the type information pined to the object in memory then a debugger can use the object type information in memory to match it with the object's definition in the program. That makes creating a debugger easy.

Imagine wanting to know what the object at address 0x34199920 is. If you have type info[1] you can cross reference the type info with 'generic array' and then do the same with element 2, address 0x34199920 and know it's a 'foo object'.

[1] Say the first 4 bytes is _always_ a type index that the compiler or interpreter generates.

But then what is the difference between a a collection of type object and a errasure model generic collection?

At the VM/bytecode level, not much (if anything?). The benefit comes at compile-time, where the compiler can verify that you're putting the correct types into a collection, and that you're expecting the correct types out.

> At the VM/bytecode level, not much (if anything?).

I don't think this is correct. In C# code at runtime, and in the bytecode, you can inspect types for metadata about their generic type params. It is present in the .Net bytecode.

See https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

> When a generic type or method is compiled into (bytecode), it contains metadata that identifies it as having type parameters.

from https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

But C# generics aren't erasure model collections are they?

No, they are not. The point is, it is different at the bytecode level.

You've got that completely the wrong way around. An erasing compiler has full access to the type (obviously - it's doing the erasing) and so can verify whether you're putting the correct types in or out of a collection.

Where erasure can cause issues is at runtime. For example:

    X isa List<Int>

Even if X is indeed a list of ints that information isn't held at runtime, so the test can't be supported.

Having said that in some respects this is a C# / Java ecumenical matter. Haskell, for example, doesn't bake types into output code so I suppose it erases even more that java, but it supports very rich polymorphic behaviour.

At runtime? None, it's a static (compile-time) feature, though the compiler does add some type assertions & casts automatically.

Note that this is not necessarily an issue for very statically-typed languages e.g. if I remember correctly GHC uses erased generics (they don't exist at runtime) which works fine because Haskell has neither pervasive RTTI nor specialisation, so the type erasure has ~no runtime visibility or impact.

Reply on news.ycombinator.com