I've just committed a few utility/convenience methods as below:
ListUtils:
List removeAll(Collection collection, Collection remove)
public static List retainAll(Collection collection, Collection retain)
public static List unmodifiableListCopy(Collection collection)
CollectionUtils:
Same as ListUt
I'm +1 on adding these classes, but I wholeheartedly agree with Gary's
point below. The class described by Stephen is a StringHolder, and
nothing else ;)
>neil
--- Gary Gregory <[EMAIL PROTECTED]> wrote:
> The word "Mutable" seems to carry quite a bit of baggage from all
> POVs! :-)
> When I thin
+1 - definitely the best so far.
--- ASHWIN Suresh <[EMAIL PROTECTED]> wrote:
>
>
> > I'll suggest keyvalue to positively describe the package (rather
> than
> > negatively). That name allows MapEntry, KeyValue and MultiKey.
> >
> > (data/holders/elements all seem a bit vague)
> >
> > Stephen
the Observer pattern in my eyes.
> Notifying is
> OK
> > > as a name, and possibly clearer in intent, however I'm not sure
> that a
> > > commons component named [notifying] quite sounds right. [notify]
> maybe,
> but
> > > then thats not quite r
--- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> We've had all positives so far. I'm going to take this as agreed and
> move
> the code to a new sandbox project. I reckon [observable] is probably
> the
> best name, although I'm open to offers.
I don't have strongly held opinions on the naming,
--- Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> I'm +1 on it moving out. Who is the community as far as that piece of
> code
> is concerned? Is it just a Stephen Colebourne work, ie) moving to
> joda
> makes good sense, or something by more people?
Stephen, Michael Hauer, and myself are the thr
--- __matthewHawthorne <[EMAIL PROTECTED]> wrote:
> I think it's a good idea to remove it. At this point, [collections]
> is
> so big that I'm +1 for removing all that we can. I frequently get
> OutOfMemoryExceptions when doing the maven build due to the size
> (from
> the statcvs and linkche
+1 on the package hierarchy. I especially agree with:
>> 3) The distinction between a decorator and a non-decorator is too
fine for me, and non-obvious to the user.
> I think I would support a move of the Observable classes to a
separate project, but I feel that moves the release that much furth
+1 on that.
--- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Formal bit, so all is clear
>
> Commons-collections contains a testing framework that enables the
> collections interfaces, such as Map, List and Set, to be tested. This
> framework has proved very useful, and has been requested
pache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
*/
package org.apache.commons.collections.pairs;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
/**
* Entry point for key-value
org.apache.commons.collections;
import java.util.Map;
/**
* A mutable key-value pair. Note that a KeyValuePair instance
* may not contain itself as a key or value.
*
* @since Commons Collections 3.0
* @version $Revision: $
*
* @author mailto:[EMAIL PROTECTED]">James Strachan
t;
> - Original Message -
> From: "Neil O'Toole" <[EMAIL PROTECTED]>
> > > My suggested solution is to add a class "KeyValue.java"
> containing
> > > the code from DefaultMapEntry, but not implementing Map.Entry.
> > > Defa
eclared final - thoughts on this??.
- KeyValuePair has a toString() method.
Unless there are objections, anyone want to add this to CVS?
Neil
--- Neil O'Toole <[EMAIL PROTECTED]> wrote:
> > > ** I had a swift look through [collections] and [lang], and
> didn't
> &g
e the
code, so I'll be looking into this next chance I get.
Neil
> - Original Message -
> From: "Neil O'Toole" <[EMAIL PROTECTED]>
> > > 'Record' confused me and made me think of databases. Is
> > > KeyValueHistory a better name
> > ** I had a swift look through [collections] and [lang], and didn't
> see
> > a simple KeyValuePair implementation... Have I missed this
> somewhere?
>
> DefaultMapEntry IIRC is the simple Map.Entry impl.
> Stephen
>
Although one (including my good self!) might initially think that a
key-value
ious-value} triplet. This class is frequently used
* in conjunction with Map.Entry. A constructor is provided to create
* a KeyValueRecord from a Map.Entry, and the [EMAIL
PROTECTED] #asMapEntry}
* method can be used to view an object of this class as a Map.Entry.
* Note that it is not possible
from a Map.Entry, and the [EMAIL
PROTECTED] #asMapEntry}
* method can be used to view an object of this class as a Map.Entry.
* Note that it is not possible for KeyValueRecord to implement the
Map.Entry
* interface as the #equals implementations are not compatible.
*
*
*
* @
this question might belong on a more general java list, but since i
came across the issue while doing stuff for collections, you guys are
going to have to suffer ;)
In brief, how should one javadoc when method behaviour differs (or is
more specific) in a subclass, even though that method is not o
Guys,
Sorry I haven't had a chance to read this thread - I've been on the
road since thursday. I'll be back in the real world tomorrow and i'll
get back to you all then.
- Neil
--- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> From: "Chuck Daniels" <[EMAIL PROTECTED]>
> > > sc.add("");
> >
--- Cheung Lo <[EMAIL PROTECTED]> wrote:
> Proposal for a Timeout Affected Priority Queue
> I would like to propose the adoption of the TapQueue into the
> collections
> packages but need feedback on the following issues:
>
> 1. Has anyone else had a need for a timeout affected priority queue?
>
[stephen] > My goals for [collections] is to add something small and
simple that doesn't prevent a user adding something more complex.
[michael] > I think I would prefer multiple listener interfaces and a
simple event to a single listener interface and either a hierarchy of
event classes or a type
> At first glance I don't really see the `need to override
> behavior'
> argument -- if a user doesn't like the way a static method is
> implemented, can't they just implement their own in a separate class?
>
Absolutely. I don't see any reason why utility methods should be
overridden. If a method
--- Neil O'Toole <[EMAIL PROTECTED]> wrote:
> Latest build and docs for NotifyingCollections available from:
>
> http://nettool.sourceforge.net/nc/
>
> The significant update is that NotifyingList no longer performs
> explicit range checks (and thus should
Latest build and docs for NotifyingCollections available from:
http://nettool.sourceforge.net/nc/
The significant update is that NotifyingList no longer performs
explicit range checks (and thus should now be suitable for use with
LazyList - an informal indicates that it does indeed work).
- Nei
This email gives an overview of the design of NotifyingCollections, and
addresses all of the points raised by Stephen in earlier emails.
The NotifyingCollections code is too large to post to the list, but can
be accessed at http://nettool.sourceforge.net/nc/
Design Overview
---
Noti
tives:
> Simple
> Extendable by subclassing Handler/Event
> Can swallow method calls without an exception if desired
> Can cope with invalid boolean 'collection changed' flags if desired
>
> Negatives:
> One Handler created per decorator
> Event instance not sha
--- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> I haven't forgotten this, and will release some code I've been
> working on
> for comparison soon.
> Stephen
Great, do you have a rough idea when you'll have that code out?
N.
> ----- Original Message
This is a much updated submission of the event-based notifying
decorator mechanism for collections, as discussed on the list last
month.
The package is too big to be posted to this list. The source, javadoc,
and pre-built jar can be downloaded from:
http://nettool.sourceforge.net/nc
The javado
> However, say you have a
> collection:
>
> { b, a, b, a, c }
>
> and you do:
>
> coll.removeAll( {a, c} );
>
> This removes all the a's and c's, i.e. items with indices 1, 3 and 4.
> However, the value of changeIndex would presumably be 0, and the
should read >> would presumably be 1
---
part 3 - test cases
test-org.apache.commons.collections.notifying.zip
Description: test-org.apache.commons.collections.notifying.zip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
part 2
src-org.apache.commons.collections.notifying.detailed.zip
Description: src-org.apache.commons.collections.notifying.detailed.zip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
You go away on vacation for two weeks and it's all change around here.
I read with interest the thread on observable collections, an
implementation of which I have been working on for some time. Attached
is a submission for a new package,
org.apache.commons.collections.notifying. This package
("No
> Would it make sense to layer [collections] on top of [lang], in the
> same
> manner that Xalan is layered on and includes Xerces in it's
> distribution?
> The most basic of collection-like things could be in [lang] for
> example; I
> am not fond of this either but what are our options? Don't thr
btw, I grant that naming a class "Utils" is probably asking for
trouble. But this was way back when, before we realised how many
classes there were going to be out there ;) That being said, how many
classes are there named "Document"?
--- Neil O'Toole <[EMAIL PRO
I couldn't agree more with Craig. I have come across the exact
situation he describes, where there exists classes:
com.foo.a.ClassA
com.foo.a.Utils
org.bar.ClassB
and you have code:
// MyClass.java
package com.acme.c;
import com.foo.a.*;
import org.bar.b.*;
[...]
public void myMeth
Hi Stephen, Rich,
> Would it be possible for you to refactor to remove
> UnmodifiableArrayListIterator? Thanks ;-)
No prob. Please find attached updated patches & files as per your
suggestion. The comments for each file are as per the previous message
except:
- ArrayIterator.patch : changes as b
;-)
> Stephen
>
> - Original Message -
> From: "Neil O'Toole" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List"
> <[EMAIL PROTECTED]>
> Sent: Friday, December 06, 2002 9:51 PM
> Subject: Re: [collections] private member
;-)
> Stephen
>
> - Original Message -
> From: "Neil O'Toole" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List"
> <[EMAIL PROTECTED]>
> Sent: Friday, December 06, 2002 9:51 PM
> Subject: Re: [collections] private member
would you want to do this, as it
> prevents
> > subclassing? A particular case: I wanted to created an
> > ArrayListIterator that subclasses ArrayIterator and implements the
> > ListIterator interface. With protected member access it is a simple
> and
> > elegant imple
face. With protected member access it is a simple and
elegant implementation to subclass ArrayIterator.
Thoughts on the matter?
- Neil O'Toole
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
40 matches
Mail list logo
