Just A Summary

Piers Cawley Practices Punditry

Supporting the good guys

Graeme (@mathie) Matthieson is one of the good guys. He’s also one of the people behind the Scottish Ruby Conference (né Scotland on Rails).

I spent my own money to go to the first one they ran, and it was a great conference. To judge from the tweets around this year’s conference, they’re not slacking off at all. Even though I’m back to being a Perl programmer nowadays, I wish I’d been in Edinburgh last week.

However it seems that some contemptible fuck at this year’s conference took the opportunity to walk off with Graeme’s iPhone. Way to go asshole.

So, Joe O’Brien set up a pledgie and, in slightly more than 24 hours, the pledge has raised the 500 notes required to cover the cost of replacing the phone. The pledge is still open with the suggestion that any excess will be, at Graeme’s discretion, used to buy the conference organizers a slap up feed, or donated to the Children’s Hospice Association.

So, pledge away. It’s a good cause.

Published on Mon, 29 Mar 2010 15:52:00 GMT by Piers Cawley . Tags , , ,

Falling out of love with a language

So, Giles Bowkett asked me on facebook “Why Perl?”. This is the long answer.

I’m a Perl hacker. I have been for around 16 years now. Around 5 years ago, prompted by the Pragmatic Programmer and Adam Turoff, I started looking at Ruby, and Ruby on Rails and sort of fell into maintaining Typo.

Why? I was getting hacked off with Perl.

I was coming to the end of my tenure/tether as Perl 6 Summarizer: watching a language that I still want to use before I die taking forever to get done gets wearing after a while, especially when you’re spending 8 hours a week summarizing the activities of a development community that, in parts, was verging on the toxic (it’s way better now).

I was also getting annoyed by small niggles in the way Perl 5 works. This was in the days before Moose. Stevan Little was just starting work on what became Class::MOP (as a prototype of Perl 6’s metaobject protocol) and way before the days of Devel::Declare.

Ruby seemed to be, as Matz has described it, “Perl, done right”. All the things that were pissing me off about Perl were so much easier in Ruby. I’ve joked, in a Ha Ha, only serious kind of way, that I left Perl for Ruby because I got fed up of unrolling @_, but there’s more to it than that. “Objects everywhere” fits my head. The language is dynamic. Ruby code had less boilerplate in it. Oh, and Ruby on Rails was looking very cool, even if David Heinemeier Hansson didn’t seem to have a clue about RESTful/Resourceful principles (he has rather more of a clue now). The community looked vibrant. What’s not to like?

I was a very happy Ruby programmer. It’s a great language. If you haven’t taken it out for a spin round the block, you should give it a try.

A Perl 5 rennaissance

While I was away on my failed attempt to become a maths teacher and then my Ruby sojourn, Perl 5 was waking up. If Perl 6 were declared a failure tomorrow by the people who are actually working on it (as opposed to the people who aren’t working on it, but bitch about it anyway – see some of chromatic’s more intemperate posts about those people), then it will still have had value for the way it’s inspired members of the Perl 5 community to nick the good bits and make them happen in Perl 5.

Stevan finished Class::MOP and it got used as the basis for Moose, which is essentially a layer of sensible defaults which sits on top of the insanely configurable and slightly more agnostic Class::MOP, which in turn sits on Perl’s weird reduced instruction set object orientation. Moose even got fast enough that it’s usable in polite company (it was always faster than Ruby), so people did. It grew an ecosystem.

Another, more recent development, is Devel::Declare. Devel::Declare is, in accordance with the long history of Perl, completely batshit insane. What it does is lets you trip the perl parser up and, while it’s standing there looking at the pretty birds flying around its head, you can run ahead and rewrite the code that it’s about to parse. Well, I say run, but what I mean is hobble ahead wearing narrow blinkers and mittens. You can accomplish amazing things in such circumstances, but it’s not fun. Devel::Declare enabled my current favourite module on CPAN: MooseX::Declare, which I’ve talked about here:

An introduction to MooseX::Declare from Piers Cawley on Vimeo.

MooseX::Declare lets me kill boilerplate. Instead of writing:

package Something;
use Moose;

has an_attribute => (is => ‘rw’);

sub a_method {
my($self, $with, $parameters)
= @_;

}

I can write:

use MooseX::Declare;
class Something {
has an_attribute => (is => ‘rw’);

method a_method($with, $parameters) { … }

}

which makes me happy. This is being done by a module which is written in Perl. It relies on a couple of modules that are implemented in C, but the bulk of the work is done in Perl itself.

So, that’s addressed one of the annoyances that led me to Ruby. What about ‘objects everwhere’. I got used writing things like:

5.times { |each| … }

Surely I’m not going to able to write:

5→times(sub {…})

in perl?

Well…

use Moose::Autobox;
sub Moose::Autobox::SCALAR::times {
my($count, $block) = @_;
1→to($count)→each_key($block);
}

5→times(sub {$_→say});

Bingo! I’d like to be able to write 5->times { $_->say } but can’t quite manage it. Give PerlX::MethodCallWithBlock a little more time though…

So, while I was away, most of the issues I had with Perl, issues that had driven me into the arms of Ruby, had been addressed.

It’s not about the bike

The new Perl tech is great, but all it does is removes barriers. I wasn’t attached to the Perl language by some huge bungee cord which was crushing me against these barriers while I sojourned in Ruby land, all the while pining for Perl. I was loving Ruby. It’s a great language.

What I am attached to is the group of friends I’ve made in the Perl community over the years. Many of whom I’ve never actually met face to face.

I felt like such a curmudgeonly old fart in the Ruby community (more specifically, the Rails community). Everything’s shiny and new and awesome. And, I suppose when you’re coming to the language from something like PHP, it is shiny and new and awesome. But it gets wearing after a while. And the arrogance? My dear! The arrogance! Admittedly, some people have a lot to be arrogant about – I still cheer DHH’s “Fuck you!” slide, but others… not so much. The kind of “Look! Ruby is uniquely suited to writing DSLs!” bullshit1 that sends chromatic off in fits of apoplexy annoyed me too, especially when I was looking at the kind of examples they were presenting as exemplary and remembering Perl from 5 years before that did the same thing but with cleaner language-like interfaces.

Coming back to Perl may well be a straightforward retreat to competence. I may be rationalizing like mad. But right now, it feels like I left Ruby because the ruby community, in the West at least, isn’t a fun place for me to be. The sexism is just the icing on that particular cake.

1 Here’s my response to Rspec:

testclass exercises Something {
test that we can create an object {
isa_ok $test→subject→new, ‘Something’;
}
}

Note the lack of perlish furniture in the test that we can create an object part. No need to quote the strings, no meaningless dos scattered about the place, no :symbols appearing at random. Okay, so I have to quote 'Something' in the implementation block, but the implementation block is unadulterated Perl. I don’t claim that only Perl can do this. I do claim that, right now at least, Ruby can’t.

Published on Wed, 10 Mar 2010 02:03:00 GMT by Piers Cawley under , , . Tags , ,

Twice now

In Ruby, when you’re doing division on integers, things can get a little counter intuitive. For instance, 6/4 is obviously 1. At least, it is until you decide that you’d rather have numbers that behave a little more like ‘real’ numbers and you do require 'mathn', a module in the Ruby standard library (ie, it comes as part of ruby). Then you enter a whole new world of rational maths, where 6 / 4 returns 3/2.

Several very fine and useful Ruby gems rely on the workings of mathn, including ruby-units, which is a spiffy tool for avoiding problems when one team is working in kilometres and the other in miles and it’s no fun at all when your space probe is suddenly incommunicado.

Other fine and dandy Ruby gems include ultrasphinx and webrat. Both of these two (and no doubt others) rely on the the fact that 302/100 == 3.

Hmm… can you see my problem?

Please, if you’re working on a gem that you intend to publish widely, then adopt the practice of never trusting that dividing an integer by another integer will return a third integer. You’re not even making yourself a hostage to some other gem, you’re making yourself a hostage to the standard library. Always do (an_integer / another).to_i and your code will be so much more robust.

I’ve got a pull request and lighthouse ticket in for webrat and, once I’ve hit ‘publish’ on this post, I shall be doing the same thing for ultrasphinx, but I’m sure there are other gems out there with the same problems. Please people, check your assumptions.

Published on Wed, 25 Nov 2009 16:49:00 GMT by Piers Cawley under , . Tags , ,

London.pm Presentation Video

Back in (crikey) February, I gave a talk at the London Perl Mongers’ technical meeting about Moose for Ruby Programmers and wrote it up here. Mike Whittaker was in the front row of the audience with his iPhone and, a couple of minutes in, started a voice recording and gave me a copy.

So… finally… I’ve taken the time I should have been using to write another article for The H and wrestled the slides and the audio into something like sync and uploaded the results to Vimeo for your viewing pleasure.

An introduction to MooseX::Declare from Piers Cawley on Vimeo.

Published on Wed, 13 May 2009 08:28:00 GMT by Piers Cawley under , , . Tags , , , , , ,

Writing parsers for fun and convenience

One aspect of coming back to Perl for ‘recreational’ programming is that if, like me, you’ve declared war on @_ and boilerplate code, then testing can be somewhat trying. The Perl testing framework that best fits my head is Test::Class, which is an excellent Perlish implementation of xUnit style testing. If you’re unfamiliar with the, library, Ovid is writing what’s shaping up to be an excellent series of introductory articles about it at http://www.modernperlbooks.com/.

The problem I’m having with Test::Class at the moment is that I can’t write:

use MooseX::Declare
class Test::Person
extends Test::Class
{
use Test::Most;

method class_under_test {’Person’} method startup : Test(startup => 1) { use_ok $test→class_under_test } …

}

Test::Class is doing too much in its initialization phase, and relies too heavily on code attributes, for it to play well with MooseX::Declare. Drat.

On reflection though, this might be a good thing, because maybe MooseX::Declare isn’t really what’s needed. What I’d like to write is something like:

use …;

testclass Test::Person
exercises Person
{
startup class under test should be usable (1 test) {
use_ok $test→class_under_test
}
}

And have the library ‘…’ expand the testclass declaration into something that looks like the first code snippet. After all, if MooseX::Declare can work without source filters, it should be possible to come up with something nicely declarative for specifying test classes.

Obviously, there’s nothing on CPAN that does this yet though. So I went fossicking through MooseX::Declare to see how it works1 and discovered thing of Lovecraftian beauty that is…

Devel::Declare

Devel::Declare is possibly the most hostilely documented library I’ve ever come across. Its documentation only begins to make sense when you already understand enough about how it works that you don’t really need the docs. What it does is to let you declare your own Perl keywords. You could, for instance use it to introduce given/when into versions of Perl that don’t have it yet. You declare your keywords and associate them with parsers. When, during its compilation phase, perl hits one of your keywords in the right context, it hands off to your parser which can then do what the hell it likes in the way of code transformation, before handing control back to Perl, which then parses the transformed code as if that was what was there all along.

So, to want to transform that testclass syntax I just pulled out of my ass into a real Test::Class package, I just need to write an appropriate parser and code generator, perform the appropriate Devel::Declare incantations, and I’m laughing.

Making progress

So far, I’ve got to the point where I have a working testclass keyword, but nothing yet for the ‘inner’ bits (setup, test, teardown, etc). I can write:

testclass Test::Person
exercises Person
{

}

testclass Test::Person::Employee
extends Test::Person
exercises Person
{

}

and, as I write this, I’m realising that the syntax I’d cooked up for using extra test helper modules:

testclass AnotherTest
helpers -More, -Exception, Carp
{

  1. use Test::More;
  2. use Test::Exception;
  3. use Carp;

}

would probably read better as:

testclass AnotherTest
+uses Carp
{

  1. use Test::Most;
  2. use Carp;

}

and also that I want this:

testclass exercises Person {

}

to build me a Test::Person class.

What’s still blowing my mind about Devel::Declare’s possibilities is that I’m no longer constrained to writing a Domain Specific Pidgin which works by building a tower of proxy objects and weird evaluation contexts to produce something that’s legal code in the host language, but which has the feel of another language. With Devel::Declare, I control the horizontal and the vertical until I choose to hand control back to Perl. Right now that means my error reporting is disgracefully bad, but it also means that I can roll a syntax that makes sense without worrying about how I’m going to get perl to parse it.

One of the things I find frustrating about writing RSpec specifications is that describe and it both want to be first class keywords – it feels like you should be able to write:

describe SomeClass, “in some context”
before each

  1. set things up
    end
it “should do something or another” … end

end

But, because RSpec works by taking advantage of Ruby’s block magic, you have to write:

describe SomeClass, “in some context” do
before :each do

  1. set things up
    end
it “should do something or another” do … end

end

I definitely prefer the version without the extraneous dos and the gratuitious : before each in the before declaration. Does anyone feel like writing devel/declare.rb?

Show us the code!

If you want to see the current state of my Test::Class::Sugar art, the place to look is http://www.github.com/pdcawley/test-class-sugar. At the time of writing it relies on http://www.github.com/rafl/devel-declare and doesn’t have anything so useful as documentation, a Makefile.PL or even any tests beyond the collection of code samples that is t/initial.t. Expect all those when and if I push it to CPAN.

Caveats

Yes, I know that this sort of metasyntactic abstraction is trivial in a Lisp. I just happen to like syntax, okay?

Update 20090312

use Test::Class::Sugar

testclass exercises Foo
+uses -Warn
{

}

Now generates

{
package Test::Foo;
use base qw/Test::Class/;
use Test::Most;
use Test::Warn

}

So that’s one hurdle jumped. And I now know how to write the various method helpers and, when I get the appropriately shaped tuits, I shall actually write the damned things.

Then all I have to do is document it.

And write up a proposal about it for YAPC::Europe.

Update 20090314

I now know what a plan looks like:

test with multiple assertions << 3 {…}

And, more importantly, I’ve implemented, and documented everything and am almost good to cut a 0.001 distribution. I need a few ducks up on CPAN, but once that’s done, we’re good and I can get on with parameterizing some of the assumptions that are hard coded at the moment.

1 Something I swore blind I wasn’t going to do in my London.pm presentation. Seems my word isn’t to be trusted…

Published on Wed, 11 Mar 2009 22:29:00 GMT by Piers Cawley under , , . Tags , , , , , , , ,

Perl: Test Infected since 1987

Here’s something interesting. This is the test directory from the very first version of Perl, released in 1987 and described by Larry as ‘a “replacement” for awk and sed’. Day one of Perl, and we already have the bare bones of the Test Anything Protocol and a prototype for Test::Harness in the TEST file.

If we truffle about in the various other branches we find other useful milestones for module developers:

  • 5.000, in 1994 came with the first iteration of h2xs which could be used to generate the basic boilerplate for a perl module. Even today, with more sophisticated module starters available, you won’t find a CPAN module of repute that doesn’t follow the basic directory structure laid down in this utility. ExtUtils::MakeMaker generates a Makefile with a test target which runs all the tests in the t subdirectory
  • 5.002, in 1996, h2xs starts stubbing test.pl
  • 5.003_12, late 1996, first version of CPAN in the Perl distribution. From day one, CPAN would not install a module if any tests failed, unless you forced it.

Meanwhile, Ruby:

  • Has only recently embraced a language test suite
  • Appears to have no standard layout for gem distributions
  • Doesn’t run tests as part of the installation process for a new gem

Is it any wonder that chromatic gets a little cranky when sweeping claims are made about how spiffy Ruby’s testing culture is?

There are those who claim that CPAN is Perl’s shining glory, but it’s not really the collection of servers, it’s the toolchain that enables it, and that toolchain can exist because so many libraries follow a pretty minimal set of conventions.

I’d love to see the Ruby community settle on a similar, single, set of conventions for the way things should work. Start with a guarantee of a either a top level Rakefile or setup.rb with build, test and install tasks. Make rubygems run the tests before installation, if the target is available, and halt the installation if they fail. Make it easy to send reports of test failures to module authors (look at the Perl CPAN and CPAN Testers sites, and their associated tooling for ideas).

I know… I should STFU And Write Some Code.

Update

Further investigation shows that gem install -t whatever does run the tests as part of the installation process. The capability is there, but it’s turned off by default. How depressing.

Published on Wed, 04 Mar 2009 16:33:00 GMT by Piers Cawley under , , . Tags , , ,

Marking time...

So, it turns out that there’s a recording of my MooseX::Declare talk at the London.pm techmeet last night. And, on listening to it, I sound rather less incoherent than I thought I did while I was delivering it (still plenty of places where I could improve. Must remember to always repeat the questions in full…), but I’m happy enough with it that I’m looking into synching it up with the slides and making a slidecast, which will probable take longer than is sensible.

So, while I do that (and write it up properly as well), I thought I’d cover something I mentioned as a throwaway about using MooseX::Declare to easily set up what I called nonce classes for testing. A nonce class, in this context, is a one shot class that you can use to test inheritance, or to provide just enough behaviour to test the class you’re actually testing or whatever.

In ruby, it’s pretty simple really:

class Child1 < Announcements::Announcement
  attr_accessor :message
end

class Child2 < Announcements::Announcement; end

class GrandKid < Child1; end

Because ruby was designed as ‘Perl with better OO’, it has a convenient, compact notation for making classes, which means it’s easy and quick to define new classes, as you need them, near to where you’re going to use them. Which is very helpful in tests.

Meanwhile, in Perl, its a wee bit more… clunky. Assuming we’re using Moose, we have:

package Child1;
use Moose;
extends 'Announcements::Announcement';

has message => (is => 'rw', isa => 'str');
no Moose;

package Child2;
use Moose;
extends 'Announcements::Announcement';
no Moose;

package GrandKid
use Moose;
extends 'Child1';
no Moose;

Yikes.

So, let’s sprinkle some MooseX::Declare magic dust over things:

use MooseX::Declare
class Child1 extends Announcements::Announcement {
    has message => (is => 'rw', isa => 'str');
}

class Child2 extends Announcements::Announcement {
}

class GrandKid extends Child1 {
}

So, even if you completely eschew the really sexy bits of MooseX::Declare and simply use its new syntax for declaring classes, you’ve still improved your golf score and reduced your hoop count.

Published on Fri, 20 Feb 2009 18:41:00 GMT by Piers Cawley under , , . Tags , , ,

Warnings are the new test failures

Have you ever tried to run Rails, Rspec, Rake or, for that matter almost any Ruby library or application that you’ve ever heard of with the -w flag? How about running Rails with taint checking on?

They aren’t exactly pleasant experiences.

Meanwhile, over in Perl land, it’s a very rare module indeed that isn’t at least clean under -w and, where appropriate, taint friendly. It would be a very irresponsible Perl Monger indeed who wrote a web framework that didn’t assume it was going to be running under the -T flag. Warnings and taint checking are annoyances, and sometimes they’re flat out wrong, but more of the time they’re useful. Which is why, in Perl, you’ll sometimes see blocks of code like:

{
no warnings;
# Code that does stuff which would trigger a warning
}

If the author is being particularly careful, she will specify which warnings to suppress – after all, there’s no need to turn off all the warnings if all you’re intending to do is redefine a method. So the prudent Perl programmer would write:

{
no warnings ‘redefine’;
# Code that redefines an existing method
}

However, there are often ways of achieving your aim even with all the warnings on.

If modules that don’t have use warnings are rare on CPAN, modules that don’t have use strict will get the unwary programmer laughed at in the street. There are modules that simply won’t work under use strict, but they tend to have no strict, either wrapped around the narrowest scope that won’t work under strict, or proudly displayed up front. The presence of a no strict implies to the interested reader that the programmer knows (or thinks he knows) what he’s doing. Writing code that does even the most implausible metaprogramming things without raising errors from strict or spamming STDERR with warnings is a matter of professional pride. Writing straightforward code that stays silent is the absolute baseline for Perl programming professionalism in my book.

Meanwhile, here in Rubyworld, there’s no equivalent of strict and it’s actively hard to start coding with warnings turned on because important frameworks like rspec and rails aren’t -w clean. In Perl, this isn’t a problem, use warnings turns warnings on lexically. Your code might well call all sorts of noisy code elsewhere but, unless you’re running with -w as well, you’ll only see the warnings for your code. If you set $VERBOSE, you’ll get all the warnings. Warnings in the log file should be like red Fs in your test output – a sign that all is not as good as it could be in your code. Sure you could just ignore the ones you know are harmless, then you’re in danger of losing the real problems in the noise.

As a gesture of goodwill, here’s alias_method_chain written so it should raise no warnings except when the ‘without’ method already exists.

def alias_method_chain(target, feature)
aliased_target, punctuation = target.to_s.sub(/([?!=])$/, ’’), $1
yield(aliased_target, punctuation) if block_given?

with_method, without_method = “#{aliased_target}_with_#{feature}#{punctuation”, “#{aliased_target}_without_#{feature}#{punctuation}”

alias_method without_method, target
remove_method target # Warning begone!
alias_method target, with_method

case
when public_method_defined?(without_method)
public target
when protected_method_defined?(without_method)
protected target
when private_method_defined?(without_method)
private_target
end
end

Published on Thu, 18 Dec 2008 10:10:00 GMT by Piers Cawley under , , . Tags , , ,

Javascript heresy

So, remind me, what’s the rationale for always using the optional ; when you’re writing Javascript? The only reasons I can think of, off the top of my head are, “Because you’ll break minifiers without it” and “Because Douglas Crockford doesn’t like it”. Well, broken minifiers that can’t parse the language correctly can kiss my fat hairy arse and argument from authority cuts little ice here.

Gareth Rushgrove pointed me at an article, which suggested that it’s because Javascript will insert a semicolon after the return in:

return
{ key: "value" }

But that’s not exactly surprising, and falls squarely into the “Don’t do that then” category of bugs, or putting it another way, the Dominus Doctrine (“You can’t just make shit up and expect the computer to know what you mean, retardo!”) applies.

Ruby also has an optional semicolon, but good style is avoid using them and we seem to survive. In fact, the Ruby parser is rather less capable than Javascript’s:

jQuery('.class')
  .addClass('whatever')
  .html('New inner HTML')


is legal Javascript, but, in Ruby you have to write:

jQuery('.class') \
  .addClass('whatever') \
  .html('New inner HTML')


because if you don’t the compiler throws its toys out of the pram and, for bonus points, the resulting parse error implies that the parser knows what you meant but decided to throw the error anyway. Ho hum.



Is there something I’ve missed? Or should I make a preemptive stand against incompetent minifiers and start writing my Javascript without semicolons?

Updates

In the comments, “James” offers a succinct piece of code using Prototype that demonstrates the problem rather neatly. In the absence of semicolons, code like:

var foo = 3
, bar = 2 + foo

[foo, bar].each(function (i) { console.log(i) })


gets parsed as

var foo = 3
, bar = 2 + foo[foo, bar].each(...)


Which isn’t exactly what you want. If I were feeling churlish, I might argue that such problems are one reason why the jQueryish way:

var foo = 3
, bar = 2 + foo
$.each([foo, bar], function () {...})


is a better way of iterating over things, but I’m not entirely sure that it is.

Looks like I’ll keep taking the semicolons.

Published on Wed, 29 Oct 2008 08:16:00 GMT by Piers Cawley under . Tags , , ,

Get sophisticated

Ruby’s primitives (Strings, Hashes, Arrays, Numbers – anything that has a literal syntax) are fine things. But that doesn’t mean you should use them everywhere. You’re often much better off wrapping them up in your own Value Objects.

Something I was working on at Railscamp this weekend threw up a great example of why it makes sense to replace primitives with more specific objects as soon as possible. Tom Morris asked me to take a look at Rena, an RDF/Semantic Web thingy.

The RDF spec describes two types of literals: a plain literal, which is a string with an optional language attribute and a typed literal, which is a string and an encoding (so the string might represent an integer, float, or anything else that your schema feels like expressing).

These literals can be output in one of (at least) two formats. We’ll start by looking at Literal#to_trix and see where that takes us:


def to_trix
  if @lang != nil && @lang != ""
    out = "<plainLiteral xml:lang=\"" + @lang + "\">"
  else
    out = "<plainLiteral>"
  end
  out += @contents
  out += "</plainLiteral>"
  return out
end

If we look over at TypedLiteral#to_trix we see a much more straightforward implementation:


def to_trix
  "<typedLiteral datatype=\"#{@encoding}\">#{@contents}</typedLiteral>"
end

How do we eliminate that ugly conditional at the beginning of Literal#to_trix, and analogous conditionals in Literal#to_n3 and TypedLiteral#to_n3?

My first thought was that I wanted to be able to write something like:


def to_trix
  "<plainLiteral#{@lang.to_trix}>#{@contents}</plainLiteral>"
end

But I didn’t want every string in the world suddenly acquiring a to_trix method. So, the solution was to intoduce a Literal::Language class and coerce our language into it, so Literal#initialize became:


def initialize(contents, lang = nil)
  @contents = contents
  @lang = Language.coerce(lang)
end  

And Language would look something like:


def self.coerce(lang)
  if lang.is_a?(self)
    return lang
  end

  new(lang.to_s.downcase)
end

def initialize(lang)
  @value = lang
end

def to_trix
  if @value == ''
    ''
  else
    " xml:lang=\"#{@value}\""
  end
end    

That ugly conditional’s still there though, so we introduced the Null Object pattern, and things started to look a good deal cleaner:


class Language
  class Null
    include Singleton
    
    def to_trix
      ''
    end
  end

  def self.coerce(lang)
    case lang
    when self
      return lang
    when nil, ''
      return Null.instance
    else
      return new(lang.to_s.downcase)
    end
  end

  ...

  def to_trix
    " xml:lang=\"#{@value}\""
  end
end

At this point, we’re still just pushing code around. If anything, we’ve got more lines of code now than when we started, but we’re starting to move behaviour nearer to the data it relates to, and our objects are starting to look like objects rather than data structures. So, we press on and make a TypedLiteral::Encoding class and, at this point things start to look interesting. TypedLiteral is starting to look almost exactly the same as Literal, but with an Encoding rather than a language.

That strange leading space in Language#to_trix is starting bug me. Let’s rewrite like so:


class Literal 
  class Language
    def format_as_trix(literal)
      "<plainLiteral xml:lang=\"#{@value}\">#{literal}</plainLiteral>"
    end

    class Null
      def format_as_trix(literal)
        "<plainLiteral>#{literal}</plainLiteral>"
      end
    end
  end

  def to_trix
    @lang.format_as_trix(@contents)
  end
end

If we make analogous change to TypedLiteral and TypedLiteral::Encoding it’s obvious that TypedLiteral and Literal were essentially the same class. Renaming @lang and @encoding to @language_or_encoding makes this blindingly obvious, so we’ll remove all of TypedLiteral’s methods except initialize. All that remains is to introduce Literal.untyped and Literal.typed factory methods to Literal, and make Literal.new into a private method and we can remove TypedLiteral in its entireity. So we change the specs to reflect the new API (wrong way round I know). Now we have a chunk of shorter, clearer code that will hopefully be easier to extend to cope with outputting literals in other formats.

Retrospective

I realise that patterns aren’t the goal of development, but by the end of the process we have a Strategy (Language/Encoding), a couple of Factory Methods (Literal.typed, Literal.untyped) and a couple of factoryish methods (Language.coerce, Encoding.coerce).

The most important aspect of the change was the introduction of the two new value object classes. Once they were introduced, they became the obvious places in which to put the varying behaviour and eliminate the repeatition of conditional code from the to_* methods. If there were to be a third output style, I would look at introducing classes like N3Stream, TrixStream and WhateverStream and have a scheme like:


def to_n3
  print_on( N3Stream.new )
end

def print_on(stream)
  language_or_encoding.print_on(stream, value)
end

but that’s almost certainly over complicating things right now.

The other thing I like about this kind of refactoring is that it drives the code towards methods and classes which obey the single responsibility principle and, at the end of the process, not only do we have fewer lines of code in total, but the individual methods involved are all substantially shorter and closer to the left hand margin.

I really should start doing this kind of thing more in my Rails practice – I keep being put off by the fact that the composed_of helper is so annoyingly not quite right and, rather than submitting a patch or making a plugin I go “Ah well… I can live with a string for a bit longer…” and I know_. From hard won experience at that, that it’s going to come and bite me. It’s already bitten Rails recently when Ruby got a new @String#tochars@ which doesn’t work like the ActiveSupport version.

Notes

If you want to see the gory details of how the change got made, Tom has merged this weekends changes into the github repository. It didn’t happen in quite the order I’ve described it in this post, but neither is this post a complete fabrication.

Changes

Corrected a stupid typo in the first block of code. Ugly condition is actually if @lang != nil && @lang != ''

Published on Wed, 20 Aug 2008 11:25:00 GMT by Piers Cawley under . Tags , , ,

Powered by Publify – Thème Frédéric de Villamil | Photo Glenn