If you use Test::Class frequently, sooner or later you'll see the following:

sub startup : Tests(startup => 1) {
    my $test = shift;
    my $engines = $test->start_engines;
    ok $engines->are_running, 'Engines should start OK.';
}

At first blush that looks sensible, but I don't think it is. I'll explain my view of the problem and hope that others can explain why I might be wrong.

Recently we were trying to fix a database performance issue and I had to hit the DBIx::Class irc channel for some advice. Specifically, mysql has an issue where a query with text or blob columns forces a disk sort under certain conditions. Suffice it to say, we hit those conditions with several text columns and benchmarking certain queries showed that removing those columns from a query significantly sped up said queries. That, unfortunately, is a bit tricky under DBIx::Class, but Matt Trout made an excellent suggestion which I later implemented. Why not do a virtual vertical partition of our tables?

You may have seen or played with the Smalltalk browser before:

If you have, you'd love it. It makes it trivial to browse through, visualize and manage a project. However, we don't have anything like this for Perl. brian d foy has tried to create a Perl browser (with code on github), but that's the only significant effort in this direction I've seen. Padre has a ticket for a subset of this functionality, but as far as I can tell, it has the same limitation as brian's approach (please correct me if I'm wrong): it's file-based.

Given Perl's dynamic nature, what if we ditched the file-based heuristics and actually examine running code? I've been thinking about this.

Wednesday I gave my roles talk at OSCON (please rate it if you've seen it) and, as usual, I came away learning things from the questions. My favourite, by far, was Perrin Harkins asking whether or not we at the BBC found method conflict resolution to be our greatest win when we switched one system over to roles instead of inheritance.

Usually people ask questions that I've either heard before or have considered, but this was a new question for me and I tried to answer on the fly, trying to make sure that I was accurately reflecting our experience. In the end, I think our biggest win was not from method conflict resolution, but in tearing apart the inheritance hierarchies and creating small, cohesive units of behaviour. When you're inheriting from the Auditing class[1] because you only need that one method, you're potentially slurping in a lot of behaviour which you do not need, a potential source of bugs. When you break Auditing out into a role, you can consume it and either exclude the methods you don't need (quick hack) or break that one method you need into a separate role (a better strategy). In short, you don't slurp in behaviour you don't need and thus have a system far more likely to model your actual problem.

It's great when intelligent questions teach you new things.

While doing research for my OSCON talk on roles, I was struck by something very interesting. You could, if you wish, group OO languages into multiple inheritance and single inheritance camps. Languages like C++ and Perl, which allow multiple inheritance, generally have taboos against it. As a result, experienced developers create designs which allow them to avoid multiple inheritance.

Single-inheritance languages, such as Ruby and Java, tend to offer language features to substitute for the lack of MI (e.g., mixins and interfaces). For these languages, use of these features is encouraged and hyped, as opposed to MI being discouraged and avoided. I'd be rather curious to know how this impacts the software design trends in those languages.

You may not have heard of Ralph Johnson and Joe Armstong, but they've been programming longer than most of us have, including OO programming longer than most of us have. It's fair to say that after you've been doing something a while, you tend to form opinions about it. Mssrs. Johnson and Armstrong have opinions and this interview with Ralph Johnson and Joe Armstrong is full of said opinions. It's brilliant. There's a great bit from Joe Armstrong where he explains what he thinks "OO" should be about. Though he doesn't use the Web browser as an example, I will. But first, it's important to quote him at length.

The BETA project started in 1976, briefly escaped into the real world and was quickly beaten to death only to have its corpse revived in academia. It's one of quite a few languages which seems destined to never catch on. It's kind of a shame as it's an interesting language, but I'm certainly in no position to change this and, in any event, am not certain I would want to.

Yesterday I posted an example of OO in BETA. Prior to that, I posted an interesting quote from the BETA researchers. In the quote, they talked about how BETA was for modelling and they didn't like inheritance for code reuse. BETA is all about modelling things properly. They talk about this a lot.

That's interesting because in yesterday's example, they have an employee pattern (class) which must have subpatterns (subclasses) for instantiation. Those subpatterns are "worker" and "salesman". That allows us to present a dilemma many OO design books include: what happens if you're a boss and one of your workers loves your products and wants to sell part-time to prove they can do it? Do you tell them "no" because your software won't model it? Of course not! You might tell them "no", but not because of software. The software is there for you, not the other way around (curiously, many businesses I've worked at seem to have overlooked this point).

So your challenge — the same one that many beginning OO design students pull their hair out over — is to decide how would you design employee objects which allow an employee to be both a worker and a salesman? Or a programmer and a manager? What about any arbitrary combinations?

Hint: roles make this much, much easier.

I've kept meaning to post an example of how the BETA programming language handles inheritance and now I have a touch of time to do so. It may seem very strange to you, but one you see what's going on, it actually makes sense.

From brian d foy's post:

During OSCON, you can meet several Perl book authors for a panel discussion, questions and answers, and socializing at Powell's Technical Books on Tuesday, July 20 at 7 pm. Bring your Perl books to get them signed by your favorite authors. Confirmed authors include:

• chromatic (Modern Perl, Perl Testing: A Developer's Notebook, Perl Hacks, Extreme Programming Pocket Guide)
• brian d foy (Effective Perl Programming, Learning Perl, Intermediate Perl, Mastering Perl)
• Joshua McAdams (Effective Perl Programming)
• Curtis "Ovid" Poe (Perl Hacks)
• Randal Schwartz (Programming perl (1st edition), Learning Perl, Intermediate Perl, Perls of Wisdom)
• Peter Scott (Perl Medic, Perl Debugged, Perl Fundamentals (DVD))

Powell's Technical Books is at 33 Northwest Park Avenue in Portland. You can take the MAX Green line (for free) from the Convention Center to NW 5th St and NW Couch St, then walk 4 blocks west to the store. There are other Powell's location, so ensure you are going to the Technical Books location.

In my my roles talk I have a long section on the B:: modules but that is so confusing to folks (as one might expect from multiple inheritance (MI) and B:: modules) that I decided to rip it out. I've replaced it with an example from the BETA programming language (all CAPS in BETA is from them, not me).

While this example is fascinating, I realised that I no longer had a damning indictment of multiple inheritance. I'm hoping that I won't need it and people will follow what's going on, but I'm now unsure and I have less time for revising this talk. However, in the process of thinking and researching about this, I discovered something interesting.

Pursuant to an idiotic discussion that I'm just not going to link to, I have formulated a general rule about type discussions:

Computer scientists have reasonable disagreements over the meaning of "static" and "dynamic" typing. Computer programmers have unreasonable disagreements over the meaning of "static" and "dynamic" typing.