bandwidth frees up a bit again.
Cheers,
-AMT
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 6:26 PM
To: Jakarta Commons Developers List
Subject: Re: [collections] [PATCH] CompositeCollection class for Commons-Collections
Stephen Colebourne
Stephen Colebourne wrote:
Sounds like a bug in IteratorChain. hasNext() should never throw UOE. (b) is
the best solution for your particuular problem however.
Stephen
I have now committed the code. I made the following changes from
Brian's last post:
1. Modified iterator to return an empty itera
Stephen,
Have you any tests to prove there is actually a performance gain?
Surely either (or both) the java compiler or the JVM should be
responsible for optimizations such as this.
Gareth.
Stephen Colebourne wrote:
From: "Brian McCallister" <[EMAIL PROTECTED]>
On Monday, November 3, 2003, a
From: "Phil Steitz" <[EMAIL PROTECTED]>
> Anyone have any objections to committing this to the decorators
subpackage?
>
> Phil
+1. The test needs work as its not a collections-testframework test.
Stephen
-
To unsubscribe, e-mai
Message- From: Phil Steitz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 10:42 AM To: Jakarta Commons
> Developers List Subject: Re: [collections] [PATCH]
> CompositeCollection class for Commons-Collections
>
>
> Arun Thomas wrote:
>>>> The last com
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 10:42 AM
To: Jakarta Commons Developers List
Subject: Re: [collections] [PATCH] CompositeCollection class for Commons-Collections
Arun Thomas wrote:
>>> The last comment suggests another possibly useful method: >>&
rst
encountered in breadth-first search. OK, I will shut up now, starting
to sound too much like a logician...Is any of this useful?
Phil
>
> Cheers, -AMT
>
> -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 8:31
2003 8:31 AM
To: Jakarta Commons Developers List
Subject: Re: [collections] [PATCH] CompositeCollection class for Commons-Collections
Brian McCallister wrote:
>
> On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:
>
>> I think that that javadoc for remove is incorrect whe
On Wednesday, November 5, 2003, at 11:31 AM, Phil Steitz wrote:
Note the similarity to the API doc for add:
"Ensures that this collection contains the specified element (optional
operation). Returns true if this collection changed as a result of the
call. (Returns false if this collection does no
Brian McCallister wrote:
On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:
I think that that javadoc for remove is incorrect when it says:
"This implementation calls remove() on each collection."
It stops when it finds the element to be removed. The contract needs
to be made more
On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:
I've updated the class in line with commons standards/documentation
etc. It
will probably end up in the decorators subpackage, as it decorates
other
collections.
A few style questions about this...
You have changed the array t
On Wednesday, November 5, 2003, at 12:10 AM, Phil Steitz wrote:
I think that that javadoc for remove is incorrect when it says:
"This implementation calls remove() on each collection."
It stops when it finds the element to be removed. The contract needs
to be made more explicit here. It might a
Stephen Colebourne wrote:
I've updated the class in line with commons standards/documentation etc. It
will probably end up in the decorators subpackage, as it decorates other
collections.
I've also changed the way the Mutator works - see what you think, it seems
cleaner/quicker I think.
The test ca
On Tuesday, November 4, 2003, at 04:00 PM, Stephen Colebourne wrote:
The main aim of the Mutator change was to make the implementation
obvious
and typesafe. IMO it does fit better with the collections API.
Okay, I don't feel strongly about it, and if it stays as an inner class
it will work fine.
- Original Message -
From: "Brian McCallister" <[EMAIL PROTECTED]>
> On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:
> > I've also changed the way the Mutator works - see what you think, it
> > seems
> > cleaner/quicker I think.
>
> Also a lot less flexible. Mutator is a
On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:
I've updated the class in line with commons standards/documentation
etc.
Much appreciated!
I've also changed the way the Mutator works - see what you think, it
seems
cleaner/quicker I think.
Also a lot less flexible. Mutator is
I've updated the class in line with commons standards/documentation etc. It
will probably end up in the decorators subpackage, as it decorates other
collections.
I've also changed the way the Mutator works - see what you think, it seems
cleaner/quicker I think.
The test case still needs looking a
On Sunday, November 2, 2003, at 07:27 PM, Stephen Colebourne wrote:
I haven't tested it, but I suspect the performance gain to be
noticable, and
[collections] has to choose the fastest implementation if it has a
choice.
Would you consider the alternative implementation I suggest?
Stephen
Perform
These strike me as a Good Idea with merit to be added to [collections]. I am
intrigued by your implementation however. The use of Closure requires two
new objects (the inner class Closure and the Holder) for each of the key
methods including size(). Perhaps you come from a Smalltalk background?
Wha
Attached is a CompositeCollection class which allows a single
Collection instance to behave correctly as a composite for N
collections, and unit tests for that class.
All operations (including iterator removal operations) which are
deterministic per the Collection spec are implemented directly.
20 matches
Mail list logo
