|
|
|
|
|
by dragonwriter
4082 days ago
|
|
As I understand, it turned out to be also useful for more than backwards compatibility (though that was entirely the reason for it) -- its why you could have Scala which its richer type system and a good interop story with Java, whereas the attempt to provide the same thing on .NET faltered in large part because of the .NET platforms reification of generics. |
|
No, the issue was a much more esoteric one (and an invented and self-inflicted constraint by the designers themselves) of migration compatibility. Consider entity A using compiled libraries (no source available) from vendor R and from vendor S in the same product. Vendor R releases a new version of his library and uses the fancy new generic collections - and refuses to maintain a non-generic version. Vendor S releases a new version of his library but refuses to provide a version that use generic collections. Library S calls code in library R. All of these need to be in place to require migration compatibility.
> its why you could have Scala which its richer type system and a good interop story with Java, whereas the attempt to provide the same thing on .NET faltered in large part because of the .NET platforms reification of generics.
Do you have a source for this? In my view it is the opposite: Reification is the right solution as it makes reified types part of the first-class system with no strange corner cases. It is type erasure that treats realized generic types as second-class citizens, with strange constraints bubbling up through the entire system.