commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [primitives] Object/JDK integration - was Proposed interface changes
Date Fri, 14 Nov 2003 23:40:06 GMT
For (hopefully) obvious reasons I would prefer to keep this at Apache.

It strikes me that two distributions within the same project would get
confusing, especially as they have the same named interfaces. Having said
that, some parts might be common (hash code generation, comparators, some
utilities).

What if I renamed the primitives sandbox to pcollections? That would avoid
confusion as we develop, and give two clear distributions if that turned out
to be the end result.

Stephen

From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> 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
>


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