Stephen Colebourne wrote:
I have applied for a sourceforge project, joda-primitives, to house the primitives sandbox code. Hopefully that will go OK and the move will then take place.
The sandbox code will be relicenced to the Joda Software Licence (my personal licence, which is a reworded Apache clone). Any objections please state now!
Stephen
----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, November 06, 2003 9:43 PM Subject: Re: [primitives] Object/JDK integration - was Proposed interface changes
I hereby accept the -1 veto on this topic (it is also valid according to
the
rules ;-). Part of my aim with this thread was to try to draw these long ongoing discussions to a final conclusion by clearly agreeing on design
once
and for all.
There are two clear and distinct philosophies here, and I don't think
either
holds all the answers. My responses to the specific points are inline below - they are intended for information rather than discussion. --- I would like to move the discussion forward into a world where there are
two
primitive collection package designs (there seems to be a demand for
both).
[primitives] has the name, history and rights to be the commons implementation. (It may be a new project, but the code is old). I hope
that
it can be improved with agreements on interface extensions, package
changes
and additions - hopefully from the similarly designed PCJ library. I also hope I can contribute to it.
Therefore, the primitives sandbox code needs either: a) a new name, remaining at commons b) a new home, away from Apache I'm guessing (b) is more likely, although I instinctively prefer Apache
and
(a). I also hope to continue some work on this codebase, wherever it is,
and
bring it to a release.
Opinions on a/b?
--- Responses inline
(1) The proposal roughly doubles the number of methods per interface
while
providing little or no additional functionality.
The additional functionality is integration.
(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.)
Although not implemented, I wanted to have the ability to effectively
plugin
a converter between primitive and Object.
(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.
This is actually a problem with the commons-proper version to some degree, however the solution of two different method names is undoubtably simpler when not extending the JDK.
(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.
I toyed with the idea of always using the term 'value' when referring to primitives, eg. addValue(), removeValue(), toValueArray(). This worked
until
I thought about the confusion when a Map was implemented. The alternative consistent approach is addInt(), removeInt(), toIntArray(). This seems an acceptable choice too.
(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.
Quite correct, and such a wrapper would have a large interface to
implement.
(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.
It is asymmetric, but that doesn't bother me especially.
(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.
True, but it doesn't strike me as a major goal of the library. (J2ME
writers
would IMO not be using large libraries anyway)
Stephen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
