Arguments against generics:
- provides little benefit, adds complexity (cost >> benefit)
- ugly, subject to abuse (see C++)
- promotes exposure of complex collections instead of properly encapsulated objects
- promotes "generic programming" style which is a departure from Java's OO roots
- God, I hope they don't use it EVERYWHERE!!
- Smalltalkers didn't need no stinking generics
Arguments for generics:
- provides type-safety and reduces dangerous casting
- provides "documentation" (enforced documentation) of what you can expect to find inside a collection thus making code more maintanable
- provides idioms that are impossible to express as concisely without them
- real programmers aren't afraid of generics, they are the one thing that will "complete" Java
- C# will have them, we need to get an upper hand
But the single best argument FOR GENERICS is:
- it's a dead horse, the cat is out of the bag, live with it or leave!
Being on the losing side is hard.. but we have to concede defeat..
(disclosure: I'm not a generics fan.. it was one reason I abandoned C++ and embraced Java)
> Arguments against generics:
> - promotes exposure of complex collections instead of
> properly encapsulated objects
how would leaving generics out discourage such exposure?
> how would leaving generics out discourage such
Leaving generics out of the spec does not discournage one from exposing collections in an API, only education does! What would say is that generics are a crutch for those that would incorrectly expose a raw collection and thus subjucate it to abuse. In this way, generics promotes this style in a mis-guided quest to obtain complete type safety.
You cannot control how people will use the language but what you can do is influence their choices. Generics create an influence that IMHO, works against good design practices.
There was an interesting book written by Dave Thomas (http://c2.com/cgi/wiki?DaveThomas) called, Smalltalk with Style. Even though the book was written for Smalltalk, there are a number of style features that do apply to Java because they go beyond language and more into what good OO code should look like. One of the style guidelines is that a method should never be more than what you can see on the screen. The reason that this guideline works in any language is because smaller methods tend to be useful in a larger number of situations. So instead of procedurally hacking in everything that needs to be done in a few methods, if you should find the core abstractions and then allow the larger pieces of functionality navigate through the more primitice methods (not unlike a workflow). The economies of generics quite simply work against this principle. In other words, If I code small methods, my code bulk will actually increase. The suggestion is that I should write longer methods. If I write longer methods, I'll most likey have to write more methods that are also longer.
One of the points of my 55K line to ~8k line refactoring that I didn't bring out is that aside from missing some key abstractions was the repeated use of "logic" in large methods that could not be reused. repackaging that logic into smaller methods allowed us to reuse that logic (we could observe DRY where as before, we were not able to).
It is for this reason alone that I will continue to argue against using generics. Type safety is not an issue for me. Yeah, it's pain if someone doesn't understand that collections should really be homogenous or if they exposed a collection and didn't document the expected type. but a far larger problem is the promotion of coding practices that add to bad design and bloat. IMHO, generics fall into this class of features.
Sorry but I have to say you just don't understand why any of the mentioned features are useful. And that does not make them bad.
Right now don't have any resources to explain it all here :-( But I just suggest you invest some time into investigating why those features were introduced.
- assert is at least better because it is shorter and can be can turned off. But you have to use it properly that's all.
- generics: http://forums.java.net/jive/post!reply.jspa?messageID=3945#3945
- metadata are intended to be used for something completely different that your example
But everything can be misused. Kitchen knife can be used as a weapon but it does not make it a bad thing.
> Sorry but I have to say you just don't understand why
> any of the mentioned features are useful. And that
> does not make them bad.
Sorry, but i understand why any of the mentioned features are useful (especially for former C++ programmers).
But, IMHO, these doubtful advantages don't excuse such significant changes of java language specification.
E.g., Enumerations can be easily implemented without j2se1.5 changes. See, for example Bloch's "Effective java programming".
IMHO, to j2se1.5, a russian proverb can be applied:
"By good intentions, the way to hell is cobbled"
[i]> Enumerations can be easily implemented without j2se1.5 changes. See, for example Bloch's "Effective java programming". [/i]
well now you hit it :-) because Bloch's type safe enumeration pattern is the very thing that lead to introducing Java 5 enumerations.
And I am happy for that.
> - introduction of generics is caused by some
> far-fetched reasons. They absolutely don't outweight
> one major drawback - java code becomes
Particularly in connection with Collections, generics make Java code a lot easier to read.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.