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 Fri, 14 Nov 2003 23:13:37 GMT
Alternatively, you're welcome to develop an alternative implementation of
primitive collections within a distinct jakarta-commons component, or even
within commons-primitives itself (although I suspect we'd all want
distinct distributions of the two approaches).  My veto was to the notion
of removing the current approach, not to developing a second approach in
one form or another.  Indeed, the commons charter recognizes, perhaps even
encourages, alternative implemenations of the same interface/design
space.

On Fri, 14 Nov 2003, Stephen Colebourne wrote:

> Unfortunately, previous attempts to get me a signin at codehaus failed,
> probably due to my ineptitude at command lines. I know the sourceforge way,
> so it'll do for the moment. If you or anyone else wants to help out, drop me
> a line.
> Stephen
>
> From: "__matthewHawthorne" <matth@phreaker.net>
> > Don't forget about codehaus.org, they have some cool projects also.  But
> > I'm not sure how hard it is to get a project going over there...
> >
> >
> >
> > 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" <scolebourne@btopenworld.com>
> > > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

-- 
- 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