Henri Yandell wrote:
I like, but I see some issues with the implementation with regards to interfaces. I just commented on your cvs commit (did that before I saw this message).I just pushed a ClassMap class in. Uses inheritence in the get, so you can do:map.put(Number.class, new NumberConverter()); Converter c = (Converter)map.get(Float.class); assuming a Converter class.
these would be special cases, right? dunno... I'll think about it though.It doesn't do anything fancy with Integer.TYPE. ie) claiming that that extends Number.class etc. Any views?
I'm not sure that an isSorted will work for CollectionUtils. Collection implementations have no restrictions on maintaining iterator order from one iterator to the next, so while the first time you call isSorted it may return true, the second time it may not. In fact, the Collections.iterator() documentation explicitly states that: "There are no guarantees concerning the order in which the elements are returned (unless this collection is an instance of some class that provides a guarantee)."Clearing out my collections package... Other things: I still need to add an isSorted to CollectionUtils, will go ahead and do that at some point. Making myself hold back until I have a unit-test is almost like hard work :)
Now, if you add that to ListUtils and perform on lists, then that seems reasonable.
This same thing can be accomplished using the three-step:I have a SortedIterator class. Basic usage being: .. Iterator iterator = ... SortedIterator si = new SortedIterator(iterator, new SomeComparator() ); .. Then it reads that iterator out in sorted order. Obviously has to suck it into memory internally. Anyone think this is of use?
List l = IteratorUtils.toList(iterator);
Collections.sort(list, new SomeComparator());
Iterator sorted = list.iterator();
to get the desired effect. Why? Because the implementation cannot do magic and turn an interator into a sorted iterator without reading the entire iterator, storing each element into a temporary store, then sorting it. Leaving it up to the user to do this three-step process (create List to store all elements, sort list, get iterator) ensures that a developer understands the memory implications (i.e. that the entire iterator is read into a list).
In other words, I don't see this as adding much functionality.
but, maybe that's just me. :)
OrderedSet -> Basically a List which doesn't allow duplicates.
ok.
LimitedList -> A List which maintains a fixed max length.
usefulness? Maybe an LRUList?
SortedLimitedList -> A List which uses a Comparator to maintain a sorted
max length. Useful to do a quick sort to find the
first N elements of a list of length L.
<Insertion Sort>
huh?
ProxySet/List. Any reason not to have these? [or even ProxyCollection]?
not that I can think of.
isn't this just a ListUtils.predicatedList(p) with a predicate, p, that checks for the right class?typed.* a Map/List/Set wrapper which enforces the Type of the value or key. So you'd do: .. List list = new TypedList(Integer.class) .. and it will throw an Exception if u pass the wrong thing in.
maybe provide the predicate to construct such a thing?
That's all that leaps out as mature for now. Apologies if I'm repeating myself with any of these, am attempting to clean out my collections package so I can force myself to use Commons Collections more. Will slowly add things as I get time and unit tests together.
cool.
Or at least the ones that aren't blown apart.
;) michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
