You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2003/11/05 20:02:40 UTC
Re: [primitives] Proposed interface changes
Some comments inline. I'll use the voting syntax, in an effort to be
concise, not formal.
On Sat, 18 Oct 2003, Stephen Colebourne wrote:
> I would like to propose the following changes for the primitives code as we
> establish it:
>
> New interface Collectable (better names?). Superinterface of XxxCollection
> and XxxMap
> - size()
> - clear()
> - isEmpty()
> There are so many times that I've needed a shared interface between
> Collection and Map
+0, I've never had that need, but it sounds reasonable to me.
> - clone()
> Fix a JDK error
I'm +1 to making the implementations cloneable, -1 to requiring this at the
interface level (e.g., I'm opposed to IntCollection extends Cloneable).
Among other problems, this will be difficult to enforce at the adapter
level.
> - isModifiable()
> This would be nice to know
I'm +0 to a Modifiable interface, but -1 to an isModifiable method. It
would be impossible to reliably implement isModifiable at the adapter
level.
Also, I'm not sure that Modifiable is the proper resolution. Some types
may allow "set" or "remove" but not "add", etc. (SingletonIterator is one
such example in the object case). Is such a collection modifiable?
> - optimize()
> For example, implemented as a trimToSize
+1
> New interface PCollection (or PrimitiveCollection):
> - toCollection()
> It should be really easy to get a JDK collection from a [primitives] one.
<Type>CollectionCollection.wrap(my<type>collection) does this already.
I'd be OK with adding a convenience method somewhere, though I'm not sure
PrimitiveCollection is the right place for it. (Perhaps
PrimitiveCollections.toCollection(<Type>Collection): Collection?)
> New methods on IntCollection (et al):
> - addAll(int[])
> - removeAll(int[])
> - containsAll(int[])
> Primitive handling is often done with arrays at present, so provide good
> integration
-0, I'd prefer simply providing an array-to-primitive collection
(or list) adapter, which would then support all these methods and more.
> - toArray(int[], int)
> Offers a way to get the primitives into a specific index in an existing
> array.
This is functionally similar to addAll(int,IntCollection)? Then as
above, I'd prefer the wrapper approach, or at least the signature
addAll(int,int[])
> New interface PList (or PrimitiveList):
> - toList()
> It should be really easy to get a JDK collection from a [primitives] one.
As above (for PCollection.toCollection).
> - removeRange(int, int)
> Although possible via subList(), this is quicker and more obvious
-0, I'm not sure that's quicker, and the "sublist as range operation"
stuff is pretty well established, but we could do worse.
> New methods on IntList (et al):
> - first()
> - last()
> Because list.get(list.size() - 1) is a pain
+1
> - indexOf(int, int)
> - lastIndexOf(int, int)
> Completes the set of index methods as per String
+1 As long as a reasonable implementation can be made within the adapters.
> - addAll(int, int[])
> Primitive handling is often done with arrays at present, so provide good
> integration
I'm not sure I understand the relationship between this and
toArray(int[],int) as above. Do you mean for toArray(int[],int) to return
a new array with the elements of the collection inserted? That sounds
useful I guess, but I'd stick it in some convenience method and not the
core interface. Again I think an adapter between a primitive array and a
primitive collection might be most helpful here.
>
> IMO, these represent a balanced extension to the JDK collection design to
> fit well in the primitives problem space. Opinions welcome.
>
> Stephen
>
>
--
- 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
Re: [primitives] Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Rodney Waldhoff" <rw...@apache.org>
> On Sat, 18 Oct 2003, Stephen Colebourne wrote:
> > New interface Collectable (better names?). Superinterface of
XxxCollection
> > and XxxMap
> > - size()
> > - clear()
> > - isEmpty()
> > There are so many times that I've needed a shared interface between
> > Collection and Map
>
> +0, I've never had that need, but it sounds reasonable to me.
This should actually go in [collections] instead/as well.
> > - isModifiable()
> > This would be nice to know
>
> I'm +0 to a Modifiable interface, but -1 to an isModifiable method. It
> would be impossible to reliably implement isModifiable at the adapter
> level.
>
> Also, I'm not sure that Modifiable is the proper resolution. Some types
> may allow "set" or "remove" but not "add", etc. (SingletonIterator is one
> such example in the object case). Is such a collection modifiable?
I've added an Unmodifiable interface to [collections]. That may suffice. The
other way that modifiability can work is an isModifiable()/setUnmodifiable()
pair. That way any collection can be made unmodifiable at any stage without
needing a separate wrapper.
> > New interface PCollection (or PrimitiveCollection):
> > - toCollection()
> > It should be really easy to get a JDK collection from a [primitives]
one.
Separate thread.
> > New methods on IntCollection (et al):
> > - addAll(int[])
> > - removeAll(int[])
> > - containsAll(int[])
> > Primitive handling is often done with arrays at present, so provide good
> > integration
>
> -0, I'd prefer simply providing an array-to-primitive collection
> (or list) adapter, which would then support all these methods and more.
This is one I do like. I'll agree that it increases the interface size, but
not real complexity. The [primitives] charter seems to be about improving
integration between objects and primitives, so this really does feel right
here.
Having to create an adaptor class just to get an array into a collection is
a PITA.
> > - toArray(int[], int)
> > Offers a way to get the primitives into a specific index in an existing
> > array.
>
> This is functionally similar to addAll(int,IntCollection)? Then as
> above, I'd prefer the wrapper approach, or at least the signature
> addAll(int,int[])
No, what I meant here was 'copy the contents of this collection into the
specified array starting at the given index in the array'. The alternative
is a System arraycopy after a toArray, or iteration both of which would be
slower. Not that important.
> > - removeRange(int, int)
> > Although possible via subList(), this is quicker and more obvious
>
> -0, I'm not sure that's quicker, and the "sublist as range operation"
> stuff is pretty well established, but we could do worse.
My thinking is that primitive collections have different usage models from
object collections, and that a range removal will be more common. Primitive
collections also have a goal of being fast, and this does avoid a sublist
object creation.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Joda-primitives is now created to house the sandbox primitives code:
http://joda-primitives.sourceforge.net
Anyone who wants to help build the implementation is welcome to contact me.
The sandbox version will be deleted today.
Stephen
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
> 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" <sc...@btopenworld.com>
> To: "Jakarta Commons Developers List" <co...@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
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <rw...@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" <ma...@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" <sc...@btopenworld.com>
> > > > To: "Jakarta Commons Developers List"
<co...@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
Re: [primitives] Object/JDK integration - was Proposed interface
changes
Posted by Rodney Waldhoff <rw...@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" <ma...@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" <sc...@btopenworld.com>
> > > To: "Jakarta Commons Developers List" <co...@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
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <ma...@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" <sc...@btopenworld.com>
> > To: "Jakarta Commons Developers List" <co...@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
Re: [primitives] Object/JDK integration - was Proposed interface
changes
Posted by __matthewHawthorne <ma...@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" <sc...@btopenworld.com>
> To: "Jakarta Commons Developers List" <co...@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
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@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
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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
Re: [primitives] Object/JDK integration - was Proposed interface
changes
Posted by __matthewHawthorne <ma...@phreaker.net>.
Comments inline...
Rodney Waldhoff wrote:
> (1) The proposal roughly doubles the number of methods per interface while
> providing little or no additional functionality.
I believe there is a consensus among those agreeing with the proposal
that it makes the API easier to use. This, of course, is a matter of
opinion. But, it comes down to a fundamental question: is usability a
part of 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.)
True. But don't the adapters behave in the same way? I would imagine
that an IntListList will throw a ClassCastException if an attempt is
made to insert a String. I see them as very similar, and I don't find
either to be misleading.
> (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.
I can't find IntList.remove(int). IntList.removeElement(int) and
IntList.remove(Object) seem to be equivalent. Are you speaking of
IntList.removeElementAt(int) vs. IntList.remove(Object). These two are
indeed very different - but I don't see the inconsistency.
> (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.
This is a valid argument is we are of the belief that changing method
names is bad. But this isn't change for change's sake... I think that
this is a side effect of the proposal.
> (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.
I think you're right. Perhaps the proposal could be modified to include
constructors which accept both primitive or object collections as
parameters? In a sense - the collection could be a bidirectional adapter,
Also, I don't see the ability to use a List as an IntList to be that
beneficial. One of the selling points of primitive collections is
efficiency and performance - since I've already got a List full of
objects, why bother?
> (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.
True, but as stated above, this could be fixed.
> (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.
This is an interesting point, as I've never seen packages constructed in
this manner. Did you purposefully structure it so that different
packages could be used in different JREs? The standard baseline of
support for jakarta-commons is Java 1.2... are you suggesting a move
backwards? If supporting pre-1.2 JREs is a requirement for certain
packages, then let's document it somewhere. Otherwise, I disagree that
this is a valid argument against the proposal.
> The current implementation provides the same functionality as the proposed
> change, in a smaller, more consistent, and more coherent fashion.
The current code contains smaller classes than the proposal, but more of
them. So it is smaller - sort of. More consistent, more coherent -
with a few tweaks, this is arguable.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [primitives] Object/JDK integration - was Proposed interface
changes
Posted by Rodney Waldhoff <rw...@apache.org>.
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
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by "Todd V. Jonker" <To...@ConsciousCode.com>.
I to preferring the sandbox's "IntCollection isa Collection" design. The
primitive collections would be worth a *lot* less to me if I couldn't use
them transparently in the rest of my standard collection code. Seems to
me that the [primitives] collections should at least play nicely with
everything in [collections].
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [primitives] Object/JDK integration - was Proposed interface
changes
Posted by __matthewHawthorne <ma...@phreaker.net>.
This is a tough one. I've gone back and forth a few times, but I think
I prefer the sandbox approach.
In general, I like the idea of being able to create an ArrayIntList and
use it as an IntList, List, or Collection. I find this easier and more
efficient that having to create an adapter such as
IntCollectionCollection or IntListList.
I think that with a good interface -> abstract class -> implementation
heirarchy (which [primitives] already has in a lot of places), this
won't complicate the work needed to implement a primitive collection by
much.
Overall, I think this would make the API easier to use and understand.
Stephen Colebourne wrote:
> As people may or may not be aware, the sandbox contains an implementation of
> primitive collections that works differently from [primitives].
>
> * [primitives] (commons-proper) - IntCollection is a top-level interface in
> its own right. A wrapper is needed to integrate with JDK Collection.
> * primitives-sandbox - IntCollection extends Collection in the JDK.
>
> These are two entirely different approaches to the problem space. Here are
> the reasons why I prefer the sandbox approach:
> - Integration - an IntCollection IS a JDK Collection, no extra wrappers
> needed
> - Number of classes - Because it is a JDK Collection, no wrappers or
> adaptors are needed
> - Possible to implement multiple collections in one class, ie. a class could
> implement both IntCollection and ShortCollection.
> Main downside:
> - Methods are named differently from JDK Collection in places because of
> return type issues
> * intInterator()
> * toIntArray()
> * removeInt()
> * getInt(index)
>
> The benefits of the commons-proper approach appear to be:
> - Simpler API for IntCollection et al, no confusion with Object world
> - Methods are named exactly as per the JDK collection (except remove)
> - Simpler implementation for each class, as it focuses on one task
> - Theory of relatively low interaction between primitive collections and
> object ones?
> Main downside:
> - Object and JDK integration - keeps Object and primitive worlds separate,
> which goes against the [primitives] charter in my mind.
>
>
> This thread allows for one final debate as to the best approach for
> primitives design. We may decide its now too late for commons-proper as it
> has a release, or we may not.
>
> If we decide to stay with the [primitives] commons-proper architecture, I
> hereby commit to remove the commons-sandbox code from the CVS to non ASF (or
> rename it if people express a desire to keep it).
>
>
> Finally, this thread started when I proposed a toCollection() method for
> IntCollection et al, and a toList() method for IntList. If we keep the
> commons-proper design we should examine these methods as to whether they are
> not the bare minimum for Object/JDK integration.
>
> Stephen
>
>
> From: "Rodney Waldhoff" <rw...@apache.org>
>
>>>New interface PCollection (or PrimitiveCollection):
>>>- toCollection()
>>>It should be really easy to get a JDK collection from a [primitives]
>
> one.
>
>><Type>CollectionCollection.wrap(my<type>collection) does this already.
>>I'd be OK with adding a convenience method somewhere, though I'm not sure
>>PrimitiveCollection is the right place for it. (Perhaps
>>PrimitiveCollections.toCollection(<Type>Collection): Collection?)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [primitives] Object/JDK integration - was Proposed interface changes
Posted by Stephen Colebourne <sc...@btopenworld.com>.
As people may or may not be aware, the sandbox contains an implementation of
primitive collections that works differently from [primitives].
* [primitives] (commons-proper) - IntCollection is a top-level interface in
its own right. A wrapper is needed to integrate with JDK Collection.
* primitives-sandbox - IntCollection extends Collection in the JDK.
These are two entirely different approaches to the problem space. Here are
the reasons why I prefer the sandbox approach:
- Integration - an IntCollection IS a JDK Collection, no extra wrappers
needed
- Number of classes - Because it is a JDK Collection, no wrappers or
adaptors are needed
- Possible to implement multiple collections in one class, ie. a class could
implement both IntCollection and ShortCollection.
Main downside:
- Methods are named differently from JDK Collection in places because of
return type issues
* intInterator()
* toIntArray()
* removeInt()
* getInt(index)
The benefits of the commons-proper approach appear to be:
- Simpler API for IntCollection et al, no confusion with Object world
- Methods are named exactly as per the JDK collection (except remove)
- Simpler implementation for each class, as it focuses on one task
- Theory of relatively low interaction between primitive collections and
object ones?
Main downside:
- Object and JDK integration - keeps Object and primitive worlds separate,
which goes against the [primitives] charter in my mind.
This thread allows for one final debate as to the best approach for
primitives design. We may decide its now too late for commons-proper as it
has a release, or we may not.
If we decide to stay with the [primitives] commons-proper architecture, I
hereby commit to remove the commons-sandbox code from the CVS to non ASF (or
rename it if people express a desire to keep it).
Finally, this thread started when I proposed a toCollection() method for
IntCollection et al, and a toList() method for IntList. If we keep the
commons-proper design we should examine these methods as to whether they are
not the bare minimum for Object/JDK integration.
Stephen
From: "Rodney Waldhoff" <rw...@apache.org>
> > New interface PCollection (or PrimitiveCollection):
> > - toCollection()
> > It should be really easy to get a JDK collection from a [primitives]
one.
>
> <Type>CollectionCollection.wrap(my<type>collection) does this already.
> I'd be OK with adding a convenience method somewhere, though I'm not sure
> PrimitiveCollection is the right place for it. (Perhaps
> PrimitiveCollections.toCollection(<Type>Collection): Collection?)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org