[sf-perl] Book(s) for learning oo perl?

[David Alban]

Again, thanks.

---------- 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
> versa?

I think Python is more often used for sysadmin-y tasks, while Ruby is
used for software engineering in the large (especially for Rails
apps).

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.

Best,

--
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.