Hacker News new | past | comments | ask | show | jobs | submit login

I have not watched the video. All of the defenses of type erasure I have read boiled down to backwards compatibility. If generics had been there from the start, the JVM and the compiler could do more with them, eliminating casts and allowing things like List<int>, getting rid of arrays entirely as a special case and allowing the compiler and JVM to optimize accordingly.



That's incorrect.

It would have been possible to implement reified generics while preserving backward compatibility, Neal Gafter had actually a proposal to do just that.

In the end, erasure won simply because it's the superior solution.


Erasure is superior to a system that would be typesafe? Please elaborate.


Erasure is just as type safe as reification.

Erasure gives you a little less flexibility to express certain constructs than reification allows, but from a type safety standpoint, the two approaches are equivalent.

If you want widen the meaning of "type safe" a bit, I would argue that reification is "less" type safe in the sense that it allows you to perform additional runtime type checks / type casts, which basically means you are second guessing the compiler and invalidating all the type soundness that it has provided you by accepting to compile your code.


It would not have allowed one to seal the loopholes demonstrated in the article?


How is reification any more type safe than erasure?


Would it not have allowed one to seal the loopholes demonstrated in the article?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: