commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [primitives] Object/JDK integration - was Proposed interface changes
Date Thu, 06 Nov 2003 20:26:18 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message