This is a very old article. It has been imported from older blogging software, and the formatting, images, etc may have been lost. Some links may be broken. Some of the information may no longer be correct. Opinions expressed in this article may no longer be held.
As you may be aware, I’m writing a book which will eventually become a free e-book. (Oh how I’m beginning to hate the e- prefix on everything vaguely related to computers. Or should I call them e-machines?) This is my initial report on how I’m getting along.
I took a short holiday in August, and brought with me the Kindle edition of Ovid’s wonderful Beginning Perl. Why? Because if you’re writing a book aimed at intermediate programmers, it’s a good idea to know what point the literature aimed at beginners takes them to. You don’t want to leave a “knowledge gap” that readers will struggle to cross over. I can report that Beginning Perl is a delight to read, and promotes some pretty good practices including erring in favour of immutable objects (which I’m a big fan of).
If you found his earlier work Metamorphoses a little hard to digest, then perhaps Beginning Perl is more your thing. (Sorry, little joke there.)
I’m already fairly familiar with chromatic’s also wonderful Modern Perl, having read it a couple of years back, but will probably need to re-familiarise myself with the OO parts of it at some point, especially because there have been a couple of new editions since then.
September has been busier than I’d expected, so I haven’t had as much time to work on writing as I’d hoped. However, I’ve gotten myself organized and set up a repository for my work which is mirrored on GitHub and BitBucket. (If anybody notices them become out of sync, please let me know. The hg-git plugin can be a little temperamental at times.)
I’ve started work on Chapter 2 of the book, which is on namespaces. Yes, I realise that Chapter 1 might be a more obvious place to start, except that Chapter 1 is supposed to serve as an introduction, and it’s a good idea to know exactly what you’re going to introduce before writing an introduction. Chapter 2 is likely to be fairly uncontroversial in its recommendations. So far, I’ve outlined the reasons why it’s a good idea to pick a namespace for your code, and some conventions to avoid collisions with modules from CPAN. I’ll soon provide more specific advice on good ways to name roles, classes, and other modules. The kind of conventions I was thinking of are stuff like:
- Prefer singular nouns for class names.
- Name classes like MyProject::Noun – this keeps the names short.
- Prefer adjectives for role names.
- Name most roles like MyProject::API::Adjective – a little longer, but these are probably things you don’t need to type out as much anyway. (Alternatively MyProject::Role::Adjective.)
- For roles that are intended to be used as traits for a particular class – that is, composed onto individual instances of the class at runtime, name them like MyProject::TraitFor::Noun::Adjective.
- Libraries of non-OO functions can live in MyProject::Util::Something, or if there’s just one such library, or a main one, call it MyProject::Util.
(To clarify, the MyProject:: part in the above is a place-holder for a not-necessarily-top-level namespace for the project.)
Do these guidelines make sense to you? What do you use? Comment below if you have ideas. ↓ ↓ ↓
I’ve also proposed a talk for the London Perl Workshop called Object-Oriented Programming: Why You’re Doing It Wrong, which I describe as “three weird tricks to make your object-oriented code more encapsulated, more reusable, and more maintainable.” What are those tricks? You’ll have to wait and see. (Or just take a look at my preliminary notes on GitHub.)
Anyway, that’s about all I have to say for September. Another report coming next month!
