Archive for May, 2007

May 25 2007

This is why God invented user comments sections

Published by Robert Fischer under Uncategorized

Check this movie out…

Funky Monkey: He’s one high tech super chimp.
Plot: Boy genius Michael Dean (Adkins) teams up with a super-talented chimpanzee and his caretaker (Modine) to take down an animal testing lab. In exchange the scientist gives the boy some pointers on the girl of his dreams.
Starring: Gilbert Godfried.

I know what you’re thinking — “How can this NOT be good?!?” These users agree!

I am a student of film, and have been for several years. And the concept of a cyber, kung-fu, satirical chimpanzee had me wondering, “Is this the film that’s going to break the mold?” Let’s face it, America has never been let down by any piece of cinema that features a simian costar. After such great classics as “Monkey Trouble” and “Dunston Checks In”, I thought that the best ideas were already taken. But then comes “Funky Monkey”. I laughed, I cried, I contemplated suicide.

Now I’ve read about demon possession in the Bible, but that still doesn’t explain why someone would create such a product of evil.

The director more than likely committed a murder-suicide with the chimpanzees after the movie debuted in a preview for some other low rent Warner Bros. film and he ended up owing money to the studio. It also doesn’t help that he wasn’t even infamous for the terrible job he did, he wasn’t even known for producing a poop-chute film.

Why was this movie ever made?

Run, don’t walk to your nearest video store and get this film! We were fortunate to get it on our MVP membership at Hollywood Video so it was free! It’s worth twice that much!

And it just gets better…

Popularity: 3% [?]

One response so far

May 25 2007

Functional Code Win of the Day

Published by Robert Fischer under Uncategorized

A method that takes the non-null values in the provided list.

Was:

    private static final <A> List<A> filterNullsFrom(final List<A> list) {
        final List<A> out = new ArrayList<A>(list.size());
        for(final A elt : list) {
            if(elt != null) {
                out.add(elt);
            }
        }
        return out;
    }

Is:

    import static org.apache.commons.collections.CollectionUtils.select;
    import static org.apache.commons.collections.PredicateUtils.notNullPredicate;
    ...
    private static final <A> List<A> filterNullsFrom(final List<A> list) {
        return new ArrayList<A>(select(list, notNullPredicate()));
    }

Popularity: 4% [?]

8 responses so far

May 17 2007

My Newest Insight into the Generics Controversy

Published by Robert Fischer under Uncategorized

Okay, I’ve had some quality time with Java5 at my newest gig, and I’m starting to understand the great controversy behind Java generics. There was a particularly painful insight I just had that has officially flipped me from stalwart supporter to reluctant supporter, and I’d like to share that with the world so they don’t have to hunt this bug down themselves.

The particular insight runs as follows. Assume that you have a class FooBar that takes parameterized type T. And assume you have a method that looks something like this:

    public T create() {
        final Object created = makeIt();
        try {
            final T out = (T) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Now, if I have a Foobar<Integer> object kicking around, and call create() in such a state that it makeIt() returns the String “42″, what would you expect to come out of create()?

Well, my thought was as follows.
Reduction 1:

    public T create() {
        final Object created = "42";
        try {
            final T out = (T) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 2:

    public Integer create() {
        final Object created = "42";
        try {
            final Integer out = (Integer) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 3:

    public Integer create() {
        try {
            final Integer out = (Integer)"42";
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 4:

    public Integer create() {
            return null;
    }

So, I’m thinking the answer should be null.

What I forgot is that Java implemented generics through type erasure (cite). So the reductions actually look like this:

Reduction 1:

    public T create() {
        final Object created = "42";
        try {
            final T out = (T) created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 2:

    public Object create() {
        final Object created = "42";
        try {
            final Object out = created;
            return out;
        } catch (ClassCastException cce) {
            return null;
        }
    }

Reduction 3:

    public Object create() {
            return "42";
    }

And that method — that one which the compiler dilligantly guarantied would only be used in places where it returns Integer objects — just returned a String.

Seriously.

I’ve got the unit tests to prove it.

EDIT: Oh, yeah, and there’s no way to go from <T> to something like T.class.

Popularity: 6% [?]

13 responses so far

« Prev

Green Web Hosting! This site hosted by DreamHost.