- 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
Maybe mdb is using a newer compiler that is behaving correctly,
but my 1.6 freaks out without these.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2910 6335cc39-0255-0410-8fd6-9bcaacd3b74c
constants up from the logger impl and back down, so we'll just use Object and
do the casting manually.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2905 6335cc39-0255-0410-8fd6-9bcaacd3b74c
- Instead of duplicating every method twice, once allowing you to specify
your own Random object, there is a static thread-safe sharable instance
that anyone can use, and a factory method to create your own instance
with a supplied Random.
- The goofy methods for picking an element from a collection but skipping
a particular value, or picking from an iterator but providing a count,
are gone.
- Instead there are two methods: pick and pluck, for picking an element
or picking and removing an element. For Iterator, only pick is available.
Optimized code paths are provided for Lists and Collections, but the API
is kept simple.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2901 6335cc39-0255-0410-8fd6-9bcaacd3b74c
adding a function type to samskivert because everyone and their mother has a
function type. This is hopefully innocuous enough and allows you to obtain
generality at the expense of verbosity:
Folds.foldLeft(new Folds.R<Integer>() {
public Integer apply (Integer zero, Integer elem) {
return Math.max(zero, elem);
}
}, 0, values);
Folds.foldLeft(new Folds.R<String>() {
public String apply (String zero, String elem) {
return zero + elem;
}
}, "", strings);
Maybe by Java 8 or 9 we'll have closures and this can become:
Folds.foldLeft((Integer b, Integer a) => Math.max(b, a))
Folds.foldLeft((String b, String a) => b + a)
or maybe:
Folds.foldLeft(#(Integer b, Integer a) { return Math.max(b, a); })
Folds.foldLeft(#(String b, String a) { return b + a; })
who knows where the syntax bike shed arguments will end up. Of course, that'll
probably hit the shelves around 2015 or so at the rate Oracle seems to be
proceeding.
If you really want to get jiggy with the functional programming, you can check
out Functional Java, which goes the whole nine yards, but sort of ignores Java's
standard collections in the process which kind of sucks:
http://functionaljava.org/
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2896 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Deadmoose