As someone who has both authored and extensively worked with the code in both formulations, I strongly believe the current approach to be the right one. So strongly in fact, that I'm going to veto (-1) the proposed change. Here's several technical reasons why:
(1) The proposal roughly doubles the number of methods per interface while providing little or no additional 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.) (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. (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. (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. (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. (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. The current implementation provides the same functionality as the proposed change, in a smaller, more consistent, and more coherent fashion. - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
