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
our tests when building samskivert with 1.5 because they depend on hsqldb which
is a 1.6 jar file. The main code base still compiles with a 1.5 compiler, so
there's no need for alarm.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2954 6335cc39-0255-0410-8fd6-9bcaacd3b74c
repository to be specified anyway. If you want to install to your local
repository, we should be using :install rather than :deploy.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2953 6335cc39-0255-0410-8fd6-9bcaacd3b74c
make Coreen understand Maven projects, but this sort of setup will be always
necessary for projects that use a totally custom build.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2941 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
version numbers and then puzzle over why things don't work when we try to use
new plugin features and forget to check what version number said feature was
introduced into the plugin and be sure that we're using that version. Yay!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2925 6335cc39-0255-0410-8fd6-9bcaacd3b74c
so that we're 100% external dependency free no matter how you build us. This is
the path to righteousness that all of our libraries must eventually go down to
save us from the dependency frying pan and put us into the dependency fire.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2924 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
charlie.groves