[sf-perl] Book(s) for learning oo perl?
extasia at extasia.org
Mon Jun 12 13:17:12 PDT 2006
---------- Forwarded message ----------
From: Quinn Weaver <qw at sf.pm.org>
Date: Jun 12, 2006 1:09 PM
Subject: Re: [sf-perl] Book(s) for learning oo perl?
To: David Alban <extasia at extasia.org>
On Mon, Jun 12, 2006 at 12:05:17PM -0700, David Alban wrote:
> Thanks very much for your response, Quinn.
Glad to be helpful. :) Do you mind if I forward this to the list? I
think it could be useful to others.
> I'm a tools guy with a sysadmin background, not an application
> programmer. Given that, would you recommend ruby over python or vice
I think Python is more often used for sysadmin-y tasks, while Ruby is
used for software engineering in the large (especially for Rails
Python is a fine choice. Just keep these points in mind:
1. Python does not have encapsulation. This means that you can reach
into a Python class and alter its variables directly, rather than
being constrained to call methods.
Some people really hate this, but, to be honest, I've never felt it's
a big deal. It's just one of those "well, then don't do that" situations.
Perl has no single OO technique. Most don't support encapsulation,
but a few (such as Class::Std) do.
Most OO texts you read harp on encapsulation a lot, as it's
a central part of the OO dogma. Just be aware that you don't get
it in Python, or in Perl (unless you use Class::Std).
2. It follows from 1 that Python does not offer a choice among public,
private, and protected inheritance. All inheritance is public.
In the Perl world, if you use Class::Std, all inheritance is private.
If you instead use the typical Perl "blessed hash" technique, all
inheritance is public, as in Python.
If you don't understand what all this means, don't worry about it.
Just be aware that this part of OO philosophy, should you read
about it in an OO book, doesn't apply to Python. In fact, I would
just skip such a section. (It's mostly for C++ people.)
Later, when you read _Perl Best Practices_, you will see Damian makes a
compelling argument that all inheritance should be private. If you
truly believe in encapsulation, then you should buy this argument.
3. Python has a weird, bolted-on syntax for declaring class methods (a.k.a.
static methods). However, class methods are a seldom-used OO
feature, so this is not a big deal either.
4. Python has weak support for multiple inheritance. Perl, if you use
blessed hashes, has weak support for multiple inheritance. Perl,
if you use Class::Std, has strong support for multiple inheritance.
My recommendation is to avoid multiple inheritance altogether
unless you find that you really need it. That is, wait till you're
actually thinking in OO terms and writing OO programs, and then,
if you find yourself wishing that a certain class could inherit from two
base classes, go back to the books.
qw (Quinn Weaver); #President, San Francisco Perl Mongers
=for information, visit http://sf.pm.org/weblog =cut
Live in a world of your own, but always welcome visitors.
More information about the SanFrancisco-pm