Here's an idea. We can make the source more manageable
and effectively limit the number of public classes by
breaking my One Decorator Class To Rule Them All into
smaller ones based on subinterface:
Bags (for SortedBags too)
predicatedBag
predicatedSortedBag
synchronizedBag
2) Subclassing would be more complex. Currently each
Predicate decorator
implementation extends another based on the interface
hierarchy. In order to
continue this, the static nested classes would need to be
package scoped,
not private. Not a big issue, but it should be noted.
I'm even
I personally like the Lists, Sets, Collections, etc naming,
too. We could put pass-through methods to
java.util.Collections on the commons.Collections class.
That way we can have our cake and eat it too.
I definitely agree that code like this is nicer:
Bag bag =
I hate ask you to do more work,
Here to help. :)
but can you separate the changes to the Bag implementations from
the improvements to the testing framework?
Well, not really. The problem is that the old Bag implementations
will fail many of the new tests in TestCollection, because
(Assuming everything that util class would
only add decorators. If it starts also doing Adapters and
such then a less concise term like wrapper is better). :-)
Jonathan
--- Jack, Paul [EMAIL PROTECTED] wrote:
Actually, that's a good point. There are some other
considerations behind
Filtering collections, that guarantees that only objects that
matches an ObjectFilter (sorry, I mean Predicate) are added?
Check the latest code in CVS; there's already a PredicateUtils
that does this. (But it is a great idea!)
TypeFilter(Predicate), that only evaluates to true if the
Um, the JDK already provides what you're looking for:
java.util.Collections.unmodifiableSet(Set set)
Collections.unmodifiableList(List list)
Collections.unmodifiableMap(Map map)
and so on. We should probably provide similar things for
Bag, SortedBag and MultiMap though.
-Paul
-Original
I too like the ComparatorUtils concept outlined below.
However, we might
want to consider whether the method names are nullFirst(Comparator) or
nullFirstComparator(Comparator) etc. I raise this because
PredicateUtils
uses the latter at the moment, and it would be nice to be
consistent
http://www.geocities.com/apachecollections/june10
Rewrote BulkTest so that it extends TestCase. It now provides
a static makeSuite(Class) method that can be used to create a
TestSuite that's displayed as a hierarchy in the swingui. The
other code's all the same, except less files needed to be
You've put a lot of work into getting these tests up and
running, and it
has exposed some problems with existing implementations, so your work
isn't without merit. In fact, I'm inclined to commit it, I would just
rather see something that utilizes JUnit's TestSuite (by subclass
probably
Okay, this is a cumulative patch; it includes the previous two.
The point of this patch is that TestMap is now hardcore. It
fully tests its collection views, by running through the tests
defined in TestSet and TestCollection on keySet(), entrySet()
and values().
It also fully tests that
I like the idea of having the functionality provided by
NullFirstComparator and NullLastComparator, but I have an
additional suggestion.
Currently, all of the classes in the comparators subpackage
are simple, and very useful. However, it seems that they'd
most often be used in conjunction with
Bugs fixed:
1. keySet().remove(Object) incorrectly returned false after
a successful removal of a null key.
2. The removeAll(Collection) and retainAll(Collection) methods
of the collection views (keySet, entrySet and values) were not
updating the modCount; therefore an iterator over a
Hi, just so you know, I'm currently working on a
TestList that your primitive collection TestCases
will be able to extend...
Might save you some work.
-Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
(This patch can be applied independently of patch #1).
Revamped TestCollection. Most of the old tests relied on
add() and addAll() to initially populate a collection. This
won't work for map collection views because they don't support
the add() and addAll() operations.
I also made
Altered the contract of Bag to conform to Collection. Altered
the implementations in DefaultMapBag to conform to Collection.
-Paul
bug9467_patch.diff
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Okay, so the goal was to be able to modularize the
tests in such a way that objects that return a collection
or map could have those return values tested using
TestMap, TestCollection etc.
How I decided to handle that was to create a new
implementation of junit.framework.Test, that allows
you
It'd also be nice to reuse the same tests for different
configurations of the same collection, eg, FastArrayList in
fast mode vs. FastArrayList in slow mode.
I'm going to go ahead and work on having fully extensible
testing suite for collections, if you've no objections...
No
My votes:
1. Eliminate TreeIterator.
2. Eliminate equals(), hashCode() and clone() from TreeNode.
3. Have iterator() make no guarantees about order; provide
the utility methods for depth-first and breadth-first.
Should the children be represented by a List or by a
Collection? Seems GUI
Now includes a junit test, which revealed several bugs,
which are now fixed.
-Paul
ReferenceMap.java
Description: Binary data
TestReferenceMap.java
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Extending AbstractMap is not the right way to add an equals,
hashcode and
toString method. I just committed real implementations for
the methods.
Was there something wrong with AbstractMap's implementations,
or did you just want to keep SequencedHashMap's superclass
as Object? I'm just
Some Feedback:
TreeNode:
1. Should it extend Cloneable? Some trees might not be
able to be Cloneable effectively (for instance, a Btree
backed by a file).
2. I think we should allow setValue to throw an
UnsupportedOperationException for unmodifiable trees.
3. What's the rationale for
Index: SequencedHashMap.java
===
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/coll
ections/SequencedHashMap.java,v
retrieving revision 1.9
diff -r1.9 SequencedHashMap.java
100c100
public class
Firstly, the Map's innards should not be exposed to the user;
what is the
point of having a Map which uses a SoftReference
implementation if users of
the Map have to know this (and thus call the purge() method
when memory is
low (how will they know?)) - the Map should handle the
Thus I propose splitting PredicateUtils in two:
PredicateCollections (#1 above)
PredicateUtils (#2 above)
Well, that still leaves us with the problem that PredicateUtils
doesn't contain all of the predicate utils. Other ideas:
1. Move PredicateUtils.and, .or, .not, .instanceof, .TRUE and
Obviously, list and map implementations respectively...
http://www.keyboardmonkey.com/next/ReserveList.java
http://www.keyboardmonkey.com/next/ReserveMap.java
Haven't looked in-depth at the code, but a few thoughts already:
1. I'd like to see implementations for all eight collection
So are you saying your patch won't work?
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101953795432669w=2
:)
That patch is still on my radar. I just haven't had the chance to do
anything with it yet. I've been swamped with too many other things.
*blush*
I thought the patch
1) What 8 interfaces?... There's only 2 that are valid.
Can't the reserve behavior be applied to:
1. java.util.Collection
2. java.util.Set
3. java.util.SortedSet
4. java.util.List
5. java.util.Map
6. java.util.SortedMap
7. org.apache.commons.collections.Bag
8.
Hi Michal,
In another thread ([SUBMIT] WeakHashSet) we've been discussing
having a two-transformer based approach that would let you handle
strings in the way you describe. The functionality we were
trying to achieve was the ability for a list or set or map to
transform objects into
And to use a RangeIterator over a collection that isn't sorted,
you'd probably create a sorted collection first:
new TreeSet(collection, comparator).subSet(first, last).iterator();
seems like it does what RangeIterator does.
-Paul
-Original Message-
From: James Strachan
// Creates a Set backed by the given map. Given
// map must be empty.
public static Set createSet(Map map);
public static SortedSet createSortedSet(SortedMap map);
This kind of depends on how a Set is backed by a Map. (You'll have to
forgive me for not knowing how this
I'm not sure a two transformer approach is all thats needed. Collections
have three basic types of method:
- input (add/set)
- query (indexOf, contains, equals, remove)
- output (get, toArray)
The Predicate/Transform proposal covers only the input group at the
moment.
A 'two transformer'
Hi,
I have a few thoughts regarding your WeakHashSet...
My first thought was to somehow integrate it with the
whole Transformer/Predicate collections we've been
discussing in another thread. So you'd have a Transformer
that converted an object into a WeakReference before
storing it in the
Hi Steve,
Your TypedList got me thinking...At first I thought, wouldn't
it be nice to specify a parameter that would allow the null
element (sometimes I need a list that allows nulls)...then I
got to thinking, actually wouldn't it be nice if the validate()
method could be overridden by a
The way I did this was:
TypedStructure interface. AbstractTypedStructure class.
IllegalTypeException exception.
Then TypedSet/List/Map implement Set/List/Map and extend
AbstractTypedStructure.
Hehehehe...we *could* use dynamic proxy classes to provide
one factory method that would work
PredicatedList would just take a Predicate in its constructor, and
anytime someone adds an element it throws an exception if the
predicate's evalute method returns false on the element. Then when
TypedList extends PredicatedList it becomes a very small class that
simply constructs a
Attached are modifications to FastArrayList, FastHashMap,
and FastTreeMap...
1. Sublists, submaps, map collection views, iterators
and list iterators are all thread-safe now. Many many
package-protected classes were added to achieve this.
2. Serialization has been somewhat improved.
3.
Is there any external behavior difference between FastArrayList and your
OptimizedFastArrayList (other than performance)? If so, can you
explicitly specify the differences and why? If not, is there a reason not
to just replace the existing FastArrayList with the faster implementation?
Can we generalize? It seems that FastHashMap
could just as easily accept any Map implementation
in its constructor. In other words, it could work
just as well with java.util.IdentityHashMap or
java.util.WeakHashMap or
org.apache.commons.collections.DoubleOrderedMap:
public class FastMap
Hi,
I noticed that version 2.0 of the Commons Collections
has been released so I thought I'd browse through the
code. While doing so I noticed something about
FastArrayList, FastHashMap and FastTreeMap.
List and Map objects can return views on their contents
that can be modified. For
40 matches
Mail list logo
