Java generics
This article by one of the sw engineers at Google about the reasons behind the decision to use the "erasure" approach for Java generics is very enlightening. The purist in me derides the limitations imposed by the approach, which are mainly due to the fact that the generic type parameters are not available at runtime, only at compile-time.
The realist in me understands that, although pure generics might be prettier, the massive Java codebase demands a way to migrate smoothly between non-generic and generic worlds, what he terms "Migration Compatibility". This allows a company to start shipping a generified version of their library that is fully forwards and backwards compatible with both environments, thus not forcing clients one step up the chain to go all generic or all non-generic - they can migrate as they write new code and leave old code intact.
Update: this article by Bruce Eckel responds to these arguments. Bear in mind that Bruce is from the dynamic typing camp.
The realist in me understands that, although pure generics might be prettier, the massive Java codebase demands a way to migrate smoothly between non-generic and generic worlds, what he terms "Migration Compatibility". This allows a company to start shipping a generified version of their library that is fully forwards and backwards compatible with both environments, thus not forcing clients one step up the chain to go all generic or all non-generic - they can migrate as they write new code and leave old code intact.
Update: this article by Bruce Eckel responds to these arguments. Bear in mind that Bruce is from the dynamic typing camp.
0 Comments:
Post a Comment
<< Home