Ten Years of Inheritance (in professional coding)

I wrote in another draft:

And fundamentally, inheritance is the wrong tool for reuse.  Providing lots of small methods to make for improved reuse through inheritance is an equally wrong approach.

I wanted to write about that a little more.

Cases where inheritance has worked out well: when I can arrange for a base class to provide a lot of functionality, and one or maybe two abstract methods overridden in the subclass.  Essentially, this comes down to “using inheritance as a mechanism to implement a strategy for some small, but critical, polymorphic bit.”  Or perhaps, “making a DSL by providing operations in a base class, then implementations in child classes.”

Probably the most accessible example of this is PHP’s FilterIterator which does little more than wrap a regular Iterator with an accept() method.

Notably, it doesn’t extend anything itself to do this.  It composes another iterator and exposes that through the OuterIterator interface.

Perl Retrospective

Perl was the first language I really did serious work in.  To this day, even though it’s dying, I still like it.  It’s different, which is at once both its major virtue, and its Achilles heel in the modern programming landscape.

Let’s talk about what makes Perl Perlish, startng with the good parts.

(Note that I use a lot of 5.10 features like say and maybe the // operator.  For the most part, assume a use v5.10; line before any code. I may not adhere to use strict; use warnings; in this post, but my production code does.)

My Coding Style

When I write code, I think in “framework” flavor.  How can I make this code modular and extensible?  How can I let other people use it without having to reimplement 80% of some method when they want to change anything about how it works, assuming they couldn’t just change this code?

I mostly build inside of classes and modules for the information hiding aspect of it.  I use Douglas Crockford’s module pattern in my JavaScript to minimize global namespace pollution.  Likewise, nearly all of my variables in Perl are lexical.

I’m also likely to pack small amounts of state and behavior into a tiny class, no matter how trivial it seems on the surface.  I’m the guy who writes a Csv class so that I can call $csv->put($data) and have all the other options (separator, etc.) baked into the class.  You could create a Tsv class with just a few lines to override the separator.  (You probably won’t ever need to. But you could, and that’s what makes me happy.)

While I get functional programming and stream programming, I generally consider it sub-optimal and avoid it where possible for PHP.

Why do I do it this way? What’s in my head when I’m programming?