4 ms·
Interesting. How do you think it would be different? I ask because the go-to is usually genetics erasure. Do you think more could or would have been different?
by kjeetgill 8y ago
Interesting. How do you think it would be different? I ask because the go-to is usually genetics erasure. Do you think more could or would have been different?
For what it's worth, Brian Goetz doesn't see type-erasure as a such a failure and defends the design choice[0].
[0]:https://m.youtube.com/watch?v=TkpcuL1t1lY https://m.youtube.com/watch?v=TkpcuL1t1lY
- hota_mazi 8y agoActually, most people who actually understand in depth the subject and the trade offs of erasure versus reification squarely side on the erasure side. Erasure is the safest way to implement generics for a long list of reasons. Reification comes with a lot of downsides, which is why most languages that support parametric polymorphism use erasure.
- kjeetgill 8y agoInteresting, do you have any resources? What people? Aside from the video I posted from Brian Goetz most of what I've read is just comments about how much people like reification in C# and how annoying those edge cases in Java are (i.e. stories from practitioners not language designers.) I'd love to read more.
- hota_mazi 8y agoThere's plenty of material out there but I'll summarize: 1. Erasure keeps you honest and prevents you from second guessing the compiler by limiting the introspection you can perform on your code. 2. Reification puts up a very high barrier to interop. Erasure systems are much more welcoming to implementing multiple languages and multiple type systems on top of them. For example, the scala.net project was abandoned because it was impossible to represent Scala's type system on .net's reified platform. 3. Reification imposes overhead because of the multitude of extra runtime checks that need to be performed. 4. Most the benefits you get from reification can be emulated on erased systems (some are admittedly more hackish on an erased runtime, but they should be rare).
- phillipcarter 8y agoI suppose if implemented flawlessly, this would be true: > Erasure keeps you honest and prevents you from second guessing the compiler by limiting the introspection you can perform on your code But the title of the article under discussion is called "The Java type system is broken", after all :)
- mcculley 8y agoI 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.
- hota_mazi 8y agoThat'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.
- mcculley 8y agoErasure is superior to a system that would be typesafe? Please elaborate.
- eeperson 8y agoHow is reification any more type safe than erasure?
- mcculley 8y agoWould it not have allowed one to seal the loopholes demonstrated in the article?
- hota_mazi 8y agoErasure 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.