My question is mainly about Scala, but since in the end it's still using JVM with its peculiarities, I also put the java
tag.
The more I use parameterized types, the more often the aforementioned question arises. Type erasure brings so much inconvenience (pattern matching like case x: A[B]
becomes impossible and so on) and there are rather heavy runtime reflection-based workarounds involving extra objects carrying type information in runtime, so I'm (from my user point of view and just of plain curiosity) wondering what decisions did lead to the current lie of the land.
Is carrying complete type everywhere up to runtime information too complicated? Or maybe there are not so much use cases for it so it isn't just being needed that often? Anyway, what are pros and cons of type erasure?
EDIT: I suppose that there are some qualified discussions, or papers, or posts etc about the subject, and I expect answers to be theoretically backed or at least contain some kind of CS-speculations, not just "runtime types are a bad practice". This is not the question about whether you did experience problems with that or not - it's about CS basis that lead to the decision.
Is carrying complete type everywhere up to runtime information too complicated?
It was done for backward compatability, not to reduce complexity.
Or maybe there are not so much use cases for it so it isn't just being needed that often?
It isn't need that often but it is confusing when it is needed.
Anyway, what are pros and cons of type erasure?
Given this has been the state of things since 2004, I suspect it really doesn't matter as it won't change significantly not matter what the pros/cons are. There is a notional plan to fix this but it is not high priority and might not make it into Java 9.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With