NB: These pages were mostly written in 2001 or so. The résumé dates are accurate but the code is aged and unlike whiskey, 8 year-old code doesn't usually taste better. For a look at my current skills and to see my CPAN modules, sample code, and code discussions, please see these pages instead: Perl resources and sample code and PangyreSoft.
Object Oriented colors, page 2
Social links
View Ashley Pond V's profile on LinkedIn
So why OOP?

Abstraction is the power of object oriented programming.
The object is an abstraction. This is incredibly powerful because humans think in abstractions. Abstraction is essentially the only way we can holistically comprehend complex problems. It's a spotting tower for alogorithms. The object, by being self-aware (of its class, abilities, attributes, and relatives), allows for design of complicated treatment that will respond as expected. This allows easy and predictable extension of functionality.

OOP aggregates code. This is how we see things naturally. When we think "chair," we don't comprehend geometry, gravity, fulcrums, carpentry, the number of legs, the upholstery or its lack, or the ergonomics of the back rest. We think of an object and this is powerful in letting us simply say, "Chair!" If we had to go through the entire rigamarole of physics, chemistry, botony, and human anatomy to request a place to rest our rears, we'd surely commit mass suicide.

OOP is ideal for high level users...
...namely other Perl hackers, because the underlying code can change radically while the programming interface remains constant or at least predictable. When you change a subroutine's code its usage often changes. When you change a method's code its usage will not need to change.

The whole speed thing is ridiculous.
A dual G4 Mac from 2000 can sustain 3 gigaflops. The G5 Macs make that look geriatric. A hundred gigaflops out of the box isn't impossible. To paraphrase the Conway, so what if your OO program is 1/2 as fast as a procedural version could be, wait six months and computer speeds will double.

And anyway...

...OOP is dramatically easier to maintain and extend.
I don't know about your time but I get paid more than my hardware does. Programmers are usually a bigger expense than hardware. OOP will save you massive amounts of time in the long haul. Some companies throw away millions of dollars maintaining libraries of disparate procedural pieces when they could consolidate massive chunks of it into just a few top level modules. Inheritance is something we didn't touch on but it's another reason OO Perl is so powerful.

Other pages

So, use it or not? (page 1)

Use it for any complicated code that others will have to deal with. Use it no matter how small the script is if there are other scripts that are similar and could be combined in a family. Use it for anything that’s not a shell script in shift()‘s clothing. And start with it. It does take a little longer at the outset, so if you start a project procedurally and half-way through realize it was a job for OOP, you’ll be sorry. No one likes rewriting code, especially one’s own.

Let’s get back to our HTML text coloring module.

OOPminiscule.pm again

Line 1 we declare the package. We are running without strict which is a no-no but hey, 11 lines of code for a full OOP color module, it’s fun to say, “I can write that module in 11 lines.”

new() is a constructor for the shell of the object. We are never going to have real methods. All methods will be AUTOLOADED. The object is nothing but a placeholder for the namespace that has the AUTOLOAD() we need to construct color methods as we go.

Because our object is a shell, a placeholder, a false object, we don’t care about what it is. Objects are typically constructed of hashes or things that look like hashes. The inimitably flexible Perl don’t give a rat’s rectum what your object is based on. You can make objects from any data types or even as closures or regexes. In this case, it makes no difference so we make the object of the quickest, most innocuous data type: a scalar, \$empty_scalar. sub new { return bless \$empty_scalar, shift } Blesses the namespace (so we have access to its AUTOLOAD) into an empty scalar.

Then we add our AUTOLOAD to take care of automatically creating any color making methods we need as we go.

So why aren’t we done? It’s broken and missing functionality.


print $c->003399('Oooooh, blue.');

doesn’t give us a nice #003399 color. When we try to use it in a script. It gives us something along these lines…

Illegal octal digit '9' at end of line
Number found where operator expected, near "->003399"
        (Missing operator before 003399?)
syntax error, near "->003399"
Execution of aborted due to compilation errors.

Let’s fix it. The problem is that AUTOLOAD will work fine on anything that fits the definition of a perl subroutine. I.e. /^[_a-zA-Z]\w*$/. Subroutines cannot start with a number. So calling 003399() as a method (via AUTOLOAD) breaks the script.

Take 1.5, miniscule with hexadecimal colors

We’ve changed three lines of code.

$AUTOLOAD =~ /^.+::(\w+)$/;
    my $color = substr($1,0,3) eq 'hex' ?
        '#' . substr($1,3,8) : $1;
Take 2, OOPminimal

Final version

The comments make it look large but the module has less than 50 lines of code.

OOP color module, take 3


This example is not the best to demonstrate the power of OOP. In fact, it borders on the “silly gimick” warned of in the introduction and if this is all you ever want it to do, a procedural module would be superior. An object would have to have attributes and perhaps work with inheritance to show its real power. Still, this example has the advantage of being brief. :)

I’ve picked up OOP from many sources including:

Conway, Damian. Object Oriented Perl.
        Manning Publications (1884777791). 1999.

Christiansen, Tom. "perltoot." perldoc. 1997.
Search these pages via Google
Text, original code, fonts, and graphics ©1990-2009 Ashley Pond V.