Rodney Waldhoff wrote:
(1) The proposal roughly doubles the number of methods per interface while providing little or no additional functionality.
I believe there is a consensus among those agreeing with the proposal that it makes the API easier to use. This, of course, is a matter of opinion. But, it comes down to a fundamental question: is usability a part of functionality?
(2) The proposed API is misleading. Every resulting interface and implementation contains many methods that declare an Object parameter but in actuality only accept Objects of a specific <Type>. (E.g., IntCollection would have add(Object) method that only accepts Integer or at most Number.)
True. But don't the adapters behave in the same way? I would imagine that an IntListList will throw a ClassCastException if an attempt is made to insert a String. I see them as very similar, and I don't find either to be misleading.
(3) The proposed API is inconsistent:
(3.a) IntList.add(Object) and IntList.add(int) are more or less equivalent (assuming Object instanceof Integer), but IntList.remove(Object) and IntList.remove(int) mean two dramatically different things.
I can't find IntList.remove(int). IntList.removeElement(int) and IntList.remove(Object) seem to be equivalent. Are you speaking of IntList.removeElementAt(int) vs. IntList.remove(Object). These two are indeed very different - but I don't see the inconsistency.
(3.b) As proposed, methods that can be overloaded by changing the signatures e.g., add(Object) and add(int), will retain the same name while methods that require different return types must change the method name e.g., get(int):Object and getInt(int):int.
This is a valid argument is we are of the belief that changing method names is bad. But this isn't change for change's sake... I think that this is a side effect of the proposal.
(4) At least one of the suggested advantages of the proposed approach--that "no wrappers or adapters are needed"--is incorrect. If IntList extends List, then an IntList can be used directly wherever a List of Integers is expected, but the converse is not true: an adapter is still required to support a List of Integers where an IntList is expected.
I think you're right. Perhaps the proposal could be modified to include constructors which accept both primitive or object collections as parameters? In a sense - the collection could be a bidirectional adapter,
Also, I don't see the ability to use a List as an IntList to be that beneficial. One of the selling points of primitive collections is efficiency and performance - since I've already got a List full of objects, why bother?
(5) As a result of previous point, the proposed API is asymmetric--the way in which we treat a List of Integers as an IntList is different from the way we treat an IntList as a List of Integers.
True, but as stated above, this could be fixed.
(6) The proposed API is more demanding of the runtime environment. The current base package, being independent of java.util.*, can be used in any every released Java version (from 1.0.2 on), and in embedded/micro or sandboxed (e.g., applet) environments that do not include the java.util Collections API. Note that the time and space savings of the primitive collections API are of particular interest to these platforms/environments.
This is an interesting point, as I've never seen packages constructed in this manner. Did you purposefully structure it so that different packages could be used in different JREs? The standard baseline of support for jakarta-commons is Java 1.2... are you suggesting a move backwards? If supporting pre-1.2 JREs is a requirement for certain packages, then let's document it somewhere. Otherwise, I disagree that this is a valid argument against the proposal.
The current implementation provides the same functionality as the proposed change, in a smaller, more consistent, and more coherent fashion.
The current code contains smaller classes than the proposal, but more of them. So it is smaller - sort of. More consistent, more coherent - with a few tweaks, this is arguable.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
