metaclass

We scheduled our Ruby Fundamentals Workshop just before the Great Lakes Ruby Bash conference here in Ann Arbor, so workshop participants can stay an extra day and enjoy the conference.

Learn more on our training page.

The Great Lakes Ruby Bash is a one-day regional Ruby conference that will be held in Ann Arbor, MI on Saturday, October 11th. The conference is only $50 and includes lunch.

Registration is now open.

According to this article Eurogames tend to have the following features:

• “emphasise strategy over showiness”
• “downplay luck and conflict”
• “lean towards economic rather than martial themes”
• “strive to keep all the players at the table until the game’s end”

The linked article emphasizes that, “[Germany] specialises in ‘Eurogames’,” and that “Germans are the keenest European players.”

Even though I’m no spring chicken, I still have regular “AHA!” moments where something that puzzled me or got little notice from me suddenly falls into place. And I’m glad I do still have these moments, because they’re so much fun. I wonder how I missed things that in hindsight seem so obvious. And I’m never sure whether I’m in the minority or majority with each of these gaps in knowledge as they come up.

Anyway, I just had one of those moments. I was reading a post in a blog on statistical modeling, and I followed the link to the paper cited. And in reading the abstract, I suddenly realized why it’s called the periodic table.

Of course I know what periodic means, and I learned a bit about the periodic table in my two chemistry classes. But I guess I never asked myself why it’s called the periodic table. Now I realize it’s because, for at least a certain portion of the table, elements 18 “units” apart from another share certain properties. So there’s a periodicity of 18 for part of the table. Whoa!

I suppose part of the reason is that when I learned about properties of the elements in the periodic table, I was probably about twelve, and the word periodic didn’t mean much to me. But I took one other course in chemistry as an undergrad, and I must have understood what periodic meant by then….

Does everyone know this and I just somehow missed it?

I got an email from David Black of Ruby Central yesterday that my talk proposal had been accepted for RubyConf 2008 in Orlando, Florida. My talk will be on Friday, November 7th from 2:10 – 2:55 in Room #1.

You will see from the abstract that this is not a typical Ruby talk. Since I spoke at RubyConf 2007, I felt I had to at least submit a proposal for this year’s conference. I struggled to come up with something that would be cool and interesting, and I was failing miserably. On the final day that talk proposals were being accepted I decided to take a step back and ask myself what I could offer the Ruby community. And when I framed the problem that way, I realized that my background in neural modeling and cognitive psychology was likely unique in the Ruby community, and that that was where I should look for a topic. Two hours later I’d written the abstract for my talk.

Related links:

• Conference Web Site
• Conference Registration
• Conference Hotel Reservations

In the previous post in this series, I attempted to demonstrate some of the basic benefits of blocks by showing examples of listing, filtering, mapping, and sorting in Ruby and in Java.

In general, the Java solutions had to do most of the work themselves with their own loop constructs. However the sorting example was a little different. In Java we were able to pass some code into the Collections.sort method using Java’s anonymous inner classes. So anonymous inner classes are somewhat close to Ruby’s blocks, at least as close as we can get.

With Collections.sort, there was a Comparator interface that we implemented in-line. So if we want to see how close we can get with Java, we’ll have to create our own interface(s) for the methods we want to supply in-line and a class to hold the main logic in a series of class (i.e., static) methods. We’ll create that infrastructure once and then be able to use it repeatedly.

To outline the plan, we will do two things: create an interface for each type of function we’ll be performing on a collection, and create a class — Iterations — to hold the static utility methods that perform the basic functionality.

Recall that for comparison purposes we had Ruby and Java versions of our Account class and a way to generate test accounts. You can get those details in the previous post.

Listing

Let’s start out with the listing task. We’ll first need our infrastructure — an interface that supports doing something to each element of a collection.

public interface EachFunction<T>
{
    public void perform(T value);
}

Note that we are using Java’s generics, so this will work in a “type-safe” manner as possible.

And in our Iterations class, we’ll add the following method:

    public static<T> void each(Collection<T> inputs, EachFunction<T> function)
    {
        for (T value : inputs) {
            function.perform(value);
        }
    }

As you can see, the each method takes a collection and a class (in our example we’ll use an anonymous inner class) that implements the EachFunction interface.

With our one-time-only infrastructure in place, we can display a list of all the members in a collection with this code:

        Iterations.each(accounts,
                        new EachFunction<Account>() {
                            public void perform(Account a) {
                                System.out.println(a);
                            }
                        });
 

Let’s compare it to our Ruby solution:

  accounts.each do |account|
    puts account
  end

So the concept is the same. However, the syntax requirements is far heavier on the Java side. And, in the case of Ruby, the functionality for each is built into the Array class, where with Java we’re required to create a separate and clunky class full of static methods to house the functionality, which moves us away from a pure object-oriented implementation.

Selecting

We’ll see a similar pattern with the selecting. We’ll start off with our interface that will allow us to convey our selection criteria:

public interface SelectCondition<T>
{
    public boolean isSelected(T value);
}

We’ll create our utility method in the Iterations class:

    @SuppressWarnings("unchecked")
    public static <T> Collection<T> select(Collection<T> inputs,
                                           SelectCondition<T> condition)
    {
        try {
            Collection<T> outputs = inputs.getClass().newInstance();
            for (T value : inputs) {
                if (condition.isSelected(value)) {
                    outputs.add(value);
                }
            }
            return outputs;
        } catch(Exception e) {
            throw new UnsupportedOperationException(e);
        }
    }

We’re doing something somewhat tricky in creating a new collection to return to the caller. We take the collection passed in, ask for its class, and then call newInstance on it. Because the type information for generics is only kept at compile time — and lost at runtime (due to type erasure) — the runtime types in the assignment cannot be assured. So, to avoid a compiler warning we must add the SupressWarnings annotation.

Also, the call to newInstance can throw either InstantiationException or IllegalAccessException. So the caller is not forced to deal with these exceptions, we’ll catch them ourselves and throw UnsupportedOperationException, which, being a descendent of RuntimeException does not have to be explicitly handled by the caller.

        Collection<Account> bigAccounts =
            Iterations.select(accounts,
                              new SelectCondition<Account>() {
                                  public boolean isSelected(Account a) {
                                      return a.balance >= 10000;
                                  }
                              });

  big_accounts = accounts.select { |account| account.balance >= 10000 }

public interface MapFunction<InputT, OutputT>
{
    public OutputT mapOf(InputT value);
}

    @SuppressWarnings("unchecked")
    public static <InputT, OutputT>
        Collection<OutputT> map(Collection<InputT> inputs,
                                MapFunction<InputT, OutputT> mapper)
    {
        try {
            Collection<OutputT> outputs = inputs.getClass().newInstance();
            for (InputT value : inputs) {
                outputs.add(mapper.mapOf(value));
            }
            return outputs;
        } catch(Exception e) {
            throw new UnsupportedOperationException(e);
        }
    }

        Collection<String> firstNames =
            Iterations.map(accounts,
                           new MapFunction<Account, String>() {
                               public String mapOf(Account account) {
                                   int firstSpace = account.holder.indexOf(' ');
                                   String firstName = account.holder.substring(0, firstSpace);
                                   return firstName;
                               }
                           });

  first_names = accounts.map { |account|
    first_space = account.holder.index(' ')
    account.holder.slice(0...first_space)
  }

    static class ComparablePair<SortT extends Comparable<SortT>, DataT>
        implements Comparable<ComparablePair<SortT, DataT>>
    {
        SortT sortValue;
        DataT dataValue;

        ComparablePair(SortT sortValue, DataT dataValue)
        {
            this.sortValue = sortValue;
            this.dataValue = dataValue;
        }

        public int compareTo(ComparablePair<SortT, DataT> other)
        {
            return sortValue.compareTo(other.sortValue);
        }
    }

    @SuppressWarnings("unchecked")
    public static <DataT, SortT extends Comparable<SortT>>
        List<DataT> sortBy(List<DataT> inputs,
                           MapFunction<DataT, SortT> sortMapper)
    {
        try {
            // do this first so exceptions generated as soon as possible
            List<DataT> sortedList = inputs.getClass().newInstance();

            // sort the data (in pairs) by putting them into a sorted set
            TreeSet<ComparablePair<SortT, DataT>> sortedSet =
                new TreeSet<ComparablePair<SortT, DataT>>();
            for (DataT value : inputs) {
                ComparablePair<SortT, DataT> sortable =
                    new ComparablePair<SortT, DataT>(sortMapper.mapOf(value),
                                                     value);
                sortedSet.add(sortable);
            }

            // pull the sorted data out and put in our result list
            for (ComparablePair<SortT, DataT> pair : sortedSet) {
                sortedList.add(pair.dataValue);
            }

            return sortedList;
        } catch(Exception e) {
            throw new UnsupportedOperationException(e);
        }
    }

        Collection<Account> accountsByBalance =
            Iterations.sortBy(accounts,
                              new MapFunction<Account, Double>() {
                                  public Double mapOf(Account a) {
                                      return a.balance;
                                  }
                              });

        Collection<Account> accountsByName =
            Iterations.sortBy(accounts,
                              new MapFunction<Account, String>() {
                                  public String mapOf(Account a) {
                                      return a.holder;
                                  }
                              });

accounts_by_balance = accounts.sort_by { |account| account.balance }

accounts_by_holder = accounts.sort_by { |account| account.holder }