- Fixed wacky use of short index variable in toString's short[] handling.
- Ensured that custom separator and whether or not we're traversing collections
is properly passed to recursive calls.
automatically traverse collections, but instead simply call toString on them.
The versions that take box arguments (where the developer is clearly expressing
a desire for custom formatted collections) still do the traversal. Moved the
warning that Enumeration and Iterator are consumed into said methods.
Switched LogBuilder to use StringUtil.toString, since it now subsumes the
behavior of ArrayUtil.toString without the undesirable collection munging that
motivated its original creation.
Nixed ArrayUtil.toString/safeToString because they haven't been in the wild
long enough to be likely to have been discovered and used by third parties.
- ObserverList shouldn't extend ArrayList; bad mojo.
- Policies should be an enum.
- Use CopyOnWriteArrayList instead of our hand-rolled snapshotting.
MDB addends:
- ObserverList should be an interface (turned out to be easier to make it an
abstract class).
- WeakObserverList should be simpler, and turns out to be so, once we simplify
ObserverList public interface and remove ArraListness.
This should all be source compatible with previous usage (modulo deprecation of
the ObserverList notification constants, which most code is probably not using,
since the nice factory methods are much more concise).
cancellation. It's tempting to store the string representation as
well when the reference is cleared, but that could be anything, so
avoid the expense.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2992 6335cc39-0255-0410-8fd6-9bcaacd3b74c
There are actually 5 different implementations of quicksort in here when
one will do (the array versions could go away and call the list version,
wrapping in Arrays.asList()). But I won't touch those right now. I am
super tempted to reduce things down to one List version and one array
version.
Also it's weird that there are customized Comparators that are null-safe.
I believe I was the one who added them in the past, but I've since learned.
It's a strange undocumented "convenience" when it's easy enough for someone
to provide a null-safe comparator for comparables. (In guava you can call
Ordering.natural().nullsLast()).
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2988 6335cc39-0255-0410-8fd6-9bcaacd3b74c
If Java were invented today, you can be damn sure the array classes
would have reasonable hashCode(), equals(), and toString() implementations,
instead of falling back to Object's.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2969 6335cc39-0255-0410-8fd6-9bcaacd3b74c
It's not that it didn't exist, it just used to be on Frame. So when
I did all my 1.5 testing, I was working with a JFrame, and then at the
11th hour decided to make this function take as general a thing as
possible, so I merrily climbed up the tree in 1.6 & didn't notice that
change.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2965 6335cc39-0255-0410-8fd6-9bcaacd3b74c
As the comments say, it tries to use the nicer stuff that was added in
1.6, but falls back as needed.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2963 6335cc39-0255-0410-8fd6-9bcaacd3b74c
I'm open to suggestions as to whether this is the right thing.
I think if it were returning a view, we'd definitely want it like this.
You don't want a List<Integer> to look like a List<Number> and have
it break something when someone stuffs a Float in it.
But the argument could be made that returning a new List can surely be
seen as a List<Number> because it is not referenced anywhere else as
something more specific. Many of the guava methods allow a "re-typing"
like this, although I think they have admitted that it was a mistake and
newly added methods don't allow it.
In any case, I think that it's most proper to retain things as specifically
as possible. Why would you turn a List<Integer> into a List<Number>?
Why would you want to throw away the information? If you need to pass it
to a method that expects List<Number> then that method should be modified
to correctly accept List<? extends Number>.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2958 6335cc39-0255-0410-8fd6-9bcaacd3b74c
the specified class.
Yeah.
I've had this laying around for a long time, almost embarrassed by it.
But I keep running into places where it'd be handy, and now I'm
going for it.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2940 6335cc39-0255-0410-8fd6-9bcaacd3b74c
clearly more awesome. This is about to precipitate an upgrade from a 10 year
old hacked version of Velocity to a zero year old hacked version of Velocity
which is not going to be pleasant, but is roundabout ten years overdue.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2922 6335cc39-0255-0410-8fd6-9bcaacd3b74c
took a Function for computing weight. That would be more useful to me, usually.
The Map version could be reimplemented fairly easily with that...
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2921 6335cc39-0255-0410-8fd6-9bcaacd3b74c
of pick().
- Iterates once.
- Checks each weight for validity.
- Only generates one random number.
On that last point: huh! I don't think there's anything wrong
with what I've done, and passing a Map with all the values as 1 is
identical to calling the other form of pick on the keySet iterator.
So: maybe I can change the Iterator-based picking and plucking
to only use one random double, like this. In fact, it would make
those methods more optimal in another way: we could stop iteration
as soon as we see the Nth element, where N is (1 / random).
Deprecated getWeighted().
RFC.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2915 6335cc39-0255-0410-8fd6-9bcaacd3b74c
David Hoover