You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Ash .." <eq...@hotmail.com> on 2003/12/05 22:58:11 UTC
[primitives] roadmap
I would like to know what the general roadmap for the primitives project is,
when the next release is slated to be, what remains to be done in view of
that release, and the kind.
Ash
_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you.
http://www.msn.co.uk/internetaccess
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [primitives] roadmap
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I took that from the PCJ library - a set of interfaces and implementations
that convert a primitive type to the int needed in hashing. This is an
optional package depending on what design we go with for maps.
BTW: I'm +1 if you want a 1.1 of primitives soon.
Stephen
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
> What does "hash plugins" mean?
>
> On Tue, 9 Dec 2003, Stephen Colebourne wrote:
>
> > o.a.c.primitives - common utilities, eg XxxUtils classes
> > o.a.c.p.collection - collections
> > o.a.c.p.list - list
> > o.a.c.p.iterator - iterators
> >
> > o.a.c.p.hash - hash plugins
> > o.a.c.p.map - maps
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Rodney Waldhoff" <rw...@apache.org>
> > > I'm in favor of re-packaging for 2.0 (though I'd like to do a 1.1
release
> > > first), but I'd like to only have to do it once. What's the proposed
new
> > > structure?
> > >
> > > On Sat, 6 Dec 2003, Stephen Colebourne wrote:
> > >
> > > > Are you still happy to move to the o.a.c.primitives package
structure
> > > > (v2.0)?
> > > >
> > > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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] roadmap
Posted by Rodney Waldhoff <rw...@apache.org>.
What does "hash plugins" mean?
On Tue, 9 Dec 2003, Stephen Colebourne wrote:
> o.a.c.primitives - common utilities, eg XxxUtils classes
> o.a.c.p.collection - collections
> o.a.c.p.list - list
> o.a.c.p.iterator - iterators
>
> o.a.c.p.hash - hash plugins
> o.a.c.p.map - maps
>
> Stephen
>
> ----- Original Message -----
> From: "Rodney Waldhoff" <rw...@apache.org>
> > I'm in favor of re-packaging for 2.0 (though I'd like to do a 1.1 release
> > first), but I'd like to only have to do it once. What's the proposed new
> > structure?
> >
> > On Sat, 6 Dec 2003, Stephen Colebourne wrote:
> >
> > > Are you still happy to move to the o.a.c.primitives package structure
> > > (v2.0)?
> > >
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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] roadmap
Posted by Stephen Colebourne <sc...@btopenworld.com>.
o.a.c.primitives - common utilities, eg XxxUtils classes
o.a.c.p.collection - collections
o.a.c.p.list - list
o.a.c.p.iterator - iterators
o.a.c.p.hash - hash plugins
o.a.c.p.map - maps
Stephen
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
> I'm in favor of re-packaging for 2.0 (though I'd like to do a 1.1 release
> first), but I'd like to only have to do it once. What's the proposed new
> structure?
>
> On Sat, 6 Dec 2003, Stephen Colebourne wrote:
>
> > Are you still happy to move to the o.a.c.primitives package structure
> > (v2.0)?
> >
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [primitives] roadmap
Posted by Rodney Waldhoff <rw...@apache.org>.
I'm in favor of re-packaging for 2.0 (though I'd like to do a 1.1 release
first), but I'd like to only have to do it once. What's the proposed new
structure?
On Sat, 6 Dec 2003, Stephen Colebourne wrote:
> Are you still happy to move to the o.a.c.primitives package structure
> (v2.0)?
>
> 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] roadmap
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Are you still happy to move to the o.a.c.primitives package structure
(v2.0)?
Stephen
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
> I'd like to do a 1.1 release some time soon.
>
> This would include:
>
> a) performance improvements to <Type>List.clear
>
> b) the static Adapt class
>
> both of which are already in place.
>
> Other changes small enough to be fully backward compatiable could be
> rolled in as well.
>
> On Fri, 5 Dec 2003, Ash .. wrote:
>
> > I would like to know what the general roadmap for the primitives project
is,
> > when the next release is slated to be, what remains to be done in view
of
> > that release, and the kind.
> > Ash
> >
>
> --
> - 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] roadmap
Posted by Rodney Waldhoff <rw...@apache.org>.
I'd like to do a 1.1 release some time soon.
This would include:
a) performance improvements to <Type>List.clear
b) the static Adapt class
both of which are already in place.
Other changes small enough to be fully backward compatiable could be
rolled in as well.
On Fri, 5 Dec 2003, Ash .. wrote:
> I would like to know what the general roadmap for the primitives project is,
> when the next release is slated to be, what remains to be done in view of
> that release, and the kind.
> Ash
>
--
- 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: [collections] [contribution] CompositeSet and CompositeMap
Posted by Phil Steitz <ph...@steitz.com>.
Brian McCallister wrote:
> On Dec 8, 2003, at 10:38 PM, Phil Steitz wrote:
>
> I missed your earlier comments, unless you mean on the
> CompositeCollection submission.
No problem. Sorry about the formatting whine -- should have snipped that
:-)
>
>> Why does CompositeSet extend CompositeCollection? The setup looks a
>> bit strained to me (e.g. the type checking in the addComposited method).
>
>
> As the majority of the behavior is identical behavior inheritance make
> sense in this context. The only behavior that changes is the calculation
> of equals() and hashcode(), and the requirement that elements be unique.
> Really the composited elements don't NEED to even be sets, but it is
> convenient for avoiding the situation where modification of the
> underlieing data structure invalidates the internal state of the
> composite. An inheritance by delegation would allow the reuse of
> behavior at the expense of more code and would allow typesafe
> addComposited(...) if you mind this. It is more code in that you need
> delegating stubs, but is a minor point.
I agree this is a small point and it makes more sense given comments below.
>
>> Looking carefully at what addComposited does in CompositeSet, I am not
>> sure that I understand what CompositeSet and CompositeMap are trying
>> to do.
>
>
> They do the same things. Collision handling was added as a convenience
> -- the default behavior is to throw an IllegalArgumentException if there
> is nothing set to handle the collision. The collision handling came from
> a requirement in my original implementation. If you feel it muddies the
> implementation rather than add useful features remove it. In the
> original implementation it was separate from the concept of the strongly
> typed Mutator interface that Stephen introduced to the
> CompositeCollection which could be used separately from the mutators
> (which were specified per-method rather than via a strongly typed
> interface).
OK. I get it. I have no problem with this, just didn't fully understand
what the goal was. This is clearer from the comments below.
>
> There is a degree of partitioning that needs to occur - hence having the
> mutators undefined by default, but allowing definitions. There are
> really two concepts at play here. The first is the composite concept,
> the second is mixing in implementations of the mutators -- it
> externalizes the mutation operations as on a composite they are pretty
> much always special case operations if they are supported. The easier
> solution is to make composites immutable -- but as I mentioned, when
> originally developed I needed them to be mutable.
>
>> Also, since add() and resolveCollisions() are separate methods in the
>> mutator interface, one could presumably do inconsistent things --
>> i.e., allow "duplicates" to be added directly via add() but disallow
>> them in addComposited() by having resolveCollisions prevent duplicates.
>
>
> You are correct that people could break the class if they wanted to. The
> default behavior is to disallow mutators (OperationNotSupported), and to
> throw an IllegalArgument on collisions. If you accept responsibility for
> mixing in mutators you need to be willing to solve that problem I think.
> Disabling mutators completely by dropping the ability to specify
> mutators is an option, and prevents people from hurting themselves, but
> I personally prefer to allow them hurt themselves if they have to work
> to do it (separately define mutators), and keep the classes more
> flexible and powerful.
I guess this is a reasonable tradeoff for the flexibility.
>
>>
>> Can you explain a little more what the use cases for these things are?
>>
>
> A lot of the uses grow out of the limitations of O/R mapping. The
> typical case in which I have used them is in hierarchical aggregates
> mapped to objects from a relational database. This case has occurred
> several times in different projects I have worked on, here is a typical
> example where a Group has members but it needs to include its children's
> members in the ones it presents to clients (Group in this case decorates
> a single instance, itself, and additional child instances) :
>
> class Group
> {
> private Set members;
> /** Instances of Group */
> private Set children;
>
> public Set getMembers() {
> CompositeSet set = new CompositeSet(members);
> // Would add collision handling and mutators if real
> for (Iterator i = this.children.iterator(); i.hasNext();) {
> set.addComposited( ((Group)i.next()).getMembers());
> }
> return set;
> }
> }
>
> Specific behavior designed for includes supporting lazy-loading of the
> composited collections (don't get more information than is absolutely
> needed for a given operation as the database hit is typically far worse
> than the extra calculation), degradation of behavior as circumstances
> get unusual (collisions) but not downright broken (exceptions) rather
> than breaking for special cases (ie, in the above example, a member
> appearing at multiple levels of the hierarchy), and the ability to
> change how mutations work based on a lot of different criteria
> (factory/builder for mutators). Basically really flexible collections
> that composite nicely.
>
> An additional use case is in an SQL generator that functions via a
> query-by-criteria with automatic reordering of elements based on where
> they belong in the query. Composited collections of query elements
> (columns, tables, sub-selects (with the full panoply of elements), join
> criteria, where criteria, etc) allow for maintaining a flexible model of
> the query at any given time but still be able to access all parts for
> nice things like extracting token replacements for mapping prepared
> statement binding values to the correct place in the query when it is
> actually bound. (I cannot open up this particular library at the moment
> as it was done on company time and is the company's IP)
Thanks.
>
> If there is violent opposition to adding these, by all means please
> don't. I'm just trying to make available resources that I thought would
> be helpful and to my mind fit in well with things already in [collections].
No objections from me. I just needed some clarification on what the
design goals were. This stuff looks useful and a good fit for
[collections]. If there are no objections (and no one else gets to it
first) I will complete review of code and tests and commit.
Thanks!
Phil
>
> -Brian
>
>
>
> ---------------------------------------------------------------------
> 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: [collections] [contribution] CompositeSet and CompositeMap
Posted by Brian McCallister <br...@apache.org>.
On Dec 8, 2003, at 10:38 PM, Phil Steitz wrote:
I missed your earlier comments, unless you mean on the
CompositeCollection submission.
> * Please try to follow the [collections] style for braces.
No problem, I figured this was just an autoformat via tool of choice --
can do so if it needs it. I (maybe mistakenly) assumed that anyone
reading it would autoformat it to their preferred format anyway, and as
only a collections committer can check it in -- his or her autoformat
will work fine.
> Why does CompositeSet extend CompositeCollection? The setup looks a
> bit strained to me (e.g. the type checking in the addComposited
> method).
As the majority of the behavior is identical behavior inheritance make
sense in this context. The only behavior that changes is the
calculation of equals() and hashcode(), and the requirement that
elements be unique. Really the composited elements don't NEED to even
be sets, but it is convenient for avoiding the situation where
modification of the underlieing data structure invalidates the internal
state of the composite. An inheritance by delegation would allow the
reuse of behavior at the expense of more code and would allow typesafe
addComposited(...) if you mind this. It is more code in that you need
delegating stubs, but is a minor point.
> Looking carefully at what addComposited does in CompositeSet, I am not
> sure that I understand what CompositeSet and CompositeMap are trying
> to do.
They do the same things. Collision handling was added as a convenience
-- the default behavior is to throw an IllegalArgumentException if
there is nothing set to handle the collision. The collision handling
came from a requirement in my original implementation. If you feel it
muddies the implementation rather than add useful features remove it.
In the original implementation it was separate from the concept of the
strongly typed Mutator interface that Stephen introduced to the
CompositeCollection which could be used separately from the mutators
(which were specified per-method rather than via a strongly typed
interface).
> I understood CompositeCollection to be a convenient way to decorate a
> collection of Collections to provide a unified view. Once you try to
> control "collisions", as in the Set and Map impls, you seem to be
> headed for some kind of partition concept. Is that what you had in
> mind?
There is a degree of partitioning that needs to occur - hence having
the mutators undefined by default, but allowing definitions. There are
really two concepts at play here. The first is the composite concept,
the second is mixing in implementations of the mutators -- it
externalizes the mutation operations as on a composite they are pretty
much always special case operations if they are supported. The easier
solution is to make composites immutable -- but as I mentioned, when
originally developed I needed them to be mutable.
> Also, since add() and resolveCollisions() are separate methods in the
> mutator interface, one could presumably do inconsistent things --
> i.e., allow "duplicates" to be added directly via add() but disallow
> them in addComposited() by having resolveCollisions prevent
> duplicates.
You are correct that people could break the class if they wanted to.
The default behavior is to disallow mutators (OperationNotSupported),
and to throw an IllegalArgument on collisions. If you accept
responsibility for mixing in mutators you need to be willing to solve
that problem I think. Disabling mutators completely by dropping the
ability to specify mutators is an option, and prevents people from
hurting themselves, but I personally prefer to allow them hurt
themselves if they have to work to do it (separately define mutators),
and keep the classes more flexible and powerful.
>
> Can you explain a little more what the use cases for these things are?
>
A lot of the uses grow out of the limitations of O/R mapping. The
typical case in which I have used them is in hierarchical aggregates
mapped to objects from a relational database. This case has occurred
several times in different projects I have worked on, here is a typical
example where a Group has members but it needs to include its
children's members in the ones it presents to clients (Group in this
case decorates a single instance, itself, and additional child
instances) :
class Group
{
private Set members;
/** Instances of Group */
private Set children;
public Set getMembers() {
CompositeSet set = new CompositeSet(members);
// Would add collision handling and mutators if real
for (Iterator i = this.children.iterator(); i.hasNext();) {
set.addComposited( ((Group)i.next()).getMembers());
}
return set;
}
}
Specific behavior designed for includes supporting lazy-loading of the
composited collections (don't get more information than is absolutely
needed for a given operation as the database hit is typically far worse
than the extra calculation), degradation of behavior as circumstances
get unusual (collisions) but not downright broken (exceptions) rather
than breaking for special cases (ie, in the above example, a member
appearing at multiple levels of the hierarchy), and the ability to
change how mutations work based on a lot of different criteria
(factory/builder for mutators). Basically really flexible collections
that composite nicely.
An additional use case is in an SQL generator that functions via a
query-by-criteria with automatic reordering of elements based on where
they belong in the query. Composited collections of query elements
(columns, tables, sub-selects (with the full panoply of elements), join
criteria, where criteria, etc) allow for maintaining a flexible model
of the query at any given time but still be able to access all parts
for nice things like extracting token replacements for mapping prepared
statement binding values to the correct place in the query when it is
actually bound. (I cannot open up this particular library at the moment
as it was done on company time and is the company's IP)
If there is violent opposition to adding these, by all means please
don't. I'm just trying to make available resources that I thought would
be helpful and to my mind fit in well with things already in
[collections].
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] [contribution] CompositeSet and CompositeMap
Posted by Phil Steitz <ph...@steitz.com>.
Brian McCallister wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Dec 7, 2003, at 7:08 PM, Stephen Colebourne wrote:
>
>> I think that they probably are useful additions, however the review and
>> commit may take some time :-)
>
>
> No worries =) I don't have an immediate or near future need for them to
> be in commons-collections -- they can live happily on their own working
> against the present release. I just thought that they would fit well so
> wanted to contribute them.
>
> I'll try to keep an eye on this list for discussion in the future on
> them when someone has a chance to review, but it is high enough volume
> that things slip through sometimes.
Brian,
I had a look. I now see the changes necessary to the CompositeCollection
class and my previous comments on the earlier submission still hold:
Housekeeping:
* Please try to follow the [collections] style for braces.
Substantive:
Why does CompositeSet extend CompositeCollection? The setup looks a bit
strained to me (e.g. the type checking in the addComposited method).
Looking carefully at what addComposited does in CompositeSet, I am not
sure that I understand what CompositeSet and CompositeMap are trying to
do. I understood CompositeCollection to be a convenient way to decorate a
collection of Collections to provide a unified view. Once you try to
control "collisions", as in the Set and Map impls, you seem to be headed
for some kind of partition concept. Is that what you had in mind? Also,
since add() and resolveCollisions() are separate methods in the mutator
interface, one could presumably do inconsistent things -- i.e., allow
"duplicates" to be added directly via add() but disallow them in
addComposited() by having resolveCollisions prevent duplicates.
Can you explain a little more what the use cases for these things are?
Phil
>
> - -Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (Darwin)
>
> iD8DBQE/08H+aOuMdvjqKWcRAjQUAJ49yLhytK5FWZae1FzSEW+LtlkwvwCfR71C
> LJchgJsHh5ugSoK8V5mrbvY=
> =u7Ze
> -----END PGP SIGNATURE-----
>
>
>
> ---------------------------------------------------------------------
> 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: [collections] [contribution] CompositeSet and CompositeMap
Posted by Brian McCallister <mc...@forthillcompany.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Dec 7, 2003, at 7:08 PM, Stephen Colebourne wrote:
> I think that they probably are useful additions, however the review and
> commit may take some time :-)
No worries =) I don't have an immediate or near future need for them to
be in commons-collections -- they can live happily on their own working
against the present release. I just thought that they would fit well so
wanted to contribute them.
I'll try to keep an eye on this list for discussion in the future on
them when someone has a chance to review, but it is high enough volume
that things slip through sometimes.
- -Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQE/08H+aOuMdvjqKWcRAjQUAJ49yLhytK5FWZae1FzSEW+LtlkwvwCfR71C
LJchgJsHh5ugSoK8V5mrbvY=
=u7Ze
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] [contribution] CompositeSet and CompositeMap
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I think that they probably are useful additions, however the review and
commit may take some time :-)
Stephen
----- Original Message -----
From: "Brian McCallister" <mc...@forthillcompany.com>
> I don't use them in a specific jakarta project (actually, now that OJB
> is in db I am no longer a committer on any Jakarta projects) -- I am
> sending them as a general addition to the collections API for the same
> reason I contributed the CompositeCollection.
>
> I use CompositeSet (though in a different form than this one, which I
> reworked in line with your changes to CompositeCollection) for projects
> using OJB =)
>
> I was under the understanding that these were desired after the earlier
> discussions on CompositeCollection. My apologies if they are not.
>
> -Brian
>
> On Dec 6, 2003, at 9:19 PM, Stephen Colebourne wrote:
>
> > Did you have any particular use case in mind, or a specific jakarta
> > project?
> > Stephen
> >
> > ----- Original Message -----
> > From: "Brian McCallister" <br...@apache.org>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Saturday, December 06, 2003 7:40 PM
> > Subject: [collections] [contribution] CompositeSet and CompositeMap
> >
> >
> >> Attached are CompositeSet and CompositeMap implementations analogous
> >> to
> >> the CompositeCollection. Also attached are (collections style) unit
> >> tests, and a modified (merged from CVS seconds before sending this
> >> email) CompositeCollection required to support the CompositeSet.
> >>
> >> -Brian McCallister
> >>
> >>
> >
> >
> > -----------------------------------------------------------------------
> > -----
> > ----
> >
> >
> >> ---------------------------------------------------------------------
> >> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] [contribution] CompositeSet and CompositeMap
Posted by Brian McCallister <mc...@forthillcompany.com>.
I don't use them in a specific jakarta project (actually, now that OJB
is in db I am no longer a committer on any Jakarta projects) -- I am
sending them as a general addition to the collections API for the same
reason I contributed the CompositeCollection.
I use CompositeSet (though in a different form than this one, which I
reworked in line with your changes to CompositeCollection) for projects
using OJB =)
I was under the understanding that these were desired after the earlier
discussions on CompositeCollection. My apologies if they are not.
-Brian
On Dec 6, 2003, at 9:19 PM, Stephen Colebourne wrote:
> Did you have any particular use case in mind, or a specific jakarta
> project?
> Stephen
>
> ----- Original Message -----
> From: "Brian McCallister" <br...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, December 06, 2003 7:40 PM
> Subject: [collections] [contribution] CompositeSet and CompositeMap
>
>
>> Attached are CompositeSet and CompositeMap implementations analogous
>> to
>> the CompositeCollection. Also attached are (collections style) unit
>> tests, and a modified (merged from CVS seconds before sending this
>> email) CompositeCollection required to support the CompositeSet.
>>
>> -Brian McCallister
>>
>>
>
>
> -----------------------------------------------------------------------
> -----
> ----
>
>
>> ---------------------------------------------------------------------
>> 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: [collections] [contribution] CompositeSet and CompositeMap
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Did you have any particular use case in mind, or a specific jakarta project?
Stephen
----- Original Message -----
From: "Brian McCallister" <br...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, December 06, 2003 7:40 PM
Subject: [collections] [contribution] CompositeSet and CompositeMap
> Attached are CompositeSet and CompositeMap implementations analogous to
> the CompositeCollection. Also attached are (collections style) unit
> tests, and a modified (merged from CVS seconds before sending this
> email) CompositeCollection required to support the CompositeSet.
>
> -Brian McCallister
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> 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: [collections] [contribution] CompositeSet and CompositeMap
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Brian McCallister <br...@apache.org>:
> Attached are CompositeSet and CompositeMap implementations analogous to
> the CompositeCollection. Also attached are (collections style) unit
> tests, and a modified (merged from CVS seconds before sending this
> email) CompositeCollection required to support the CompositeSet.
>
> -Brian McCallister
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[collections] [contribution] CompositeSet and CompositeMap
Posted by Brian McCallister <br...@apache.org>.
Attached are CompositeSet and CompositeMap implementations analogous to
the CompositeCollection. Also attached are (collections style) unit
tests, and a modified (merged from CVS seconds before sending this
email) CompositeCollection required to support the CompositeSet.
-Brian McCallister
Re: [primitives] roadmap
Posted by Stephen Colebourne <sc...@btopenworld.com>.
The plan was roughly speaking to:
- move the current code into the 'correct' package, ie. primitives, probably
subdivided by interface as per collections
- use code generation to create the java files rather than cut and paste
- add map interfaces and implementations
- release
Is everyone happy to switch to the 'primitives' package name with
subpackages as per [collections]??
Stephen
----- Original Message -----
From: "Ash .." <eq...@hotmail.com>
> I would like to know what the general roadmap for the primitives project
is,
> when the next release is slated to be, what remains to be done in view of
> that release, and the kind.
> Ash
>
> _________________________________________________________________
> Find a cheaper internet access deal - choose one to suit you.
> http://www.msn.co.uk/internetaccess
>
>
> ---------------------------------------------------------------------
> 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