Z
ZMystiCat
Guest
To use a real-world example, let’s consider Java generics. Pre-generics, an implementation for ArrayList might have looked like:
Code:
public class ArrayList implements List {
private Object[] a_;
// Some implementation details
boolean Add(Object o) {
// implementation
}
Code:
public class ArrayList<T> implements List<T> {
// implementation
}
Code:
List l = new ArrayList();
Code:
private T[] a_;
Code:
boolean Add(T o) {
// implementation
}ArrayList<Object>(), but that’s a type of obscure shorthand Java tends to avoid.*In the end, Java now just erases the type, effectively treating all T as an Object. That comes with its own problems, but it doesn’t break backwards compatibility.
On the flip side, I believe Microsoft ran into the same dilemma with C# and went with the T-backed array approach. It broke all existing code, but C# now is better at generics than Java, though Java is still suitable for almost every practical use case. There’s still a lot of complaints about the limitations of type erasure, but a lot of the complaints I see about Java’s limitations come from bad software engineers who wanted to do something you shouldn’t do anyways and don’t want to put in the effort to do things right (ironically).
* Someone might argue that Java, no matter what, is still obscure with its current allowance of not providing the generic type. However, since Java’s established behavior is type erasure, I would say this isn’t the case. No matter what, you’re working with an Object-backed array and are bound by those limitations. It’s just that now those limitations are more pronounced.
I still do.
Last edited:
