object Perl

[Rob Manning]

I've spent a good deal of time developing object-oriented
applications in Java, and if I had to guess what topics were
going to be covered in the new OO Perl Programming book, I'd say
the following at least (which might answer the 'which is better' question
you posed, Jim):

Data Encapsulation/Extraction - fancy way of saying you don't have
to keep track of where your global vars are and whose using them.
This is very useful when you have methods with many arguments
or ones that take data structures as arguments.  This technique also
provides methods/functions for manipulating the internal data
(variables) "safely" - that is according to the object's purpose and
not the whim of the user which could put you into a dangerous state.

Inheritance - you can do alot by extending the class you need to suit
your purposes and changing very little of the original code.

Polymorphism - your code can do "smart" things like providing an
implementation specific version of a method that it's ancestors
define.  This allows you to focus your efforts on what makes an
object different from its relatives instead of re-writing the code
that is the shared.

Readability - people use objects and interfaces each day in every
area of life.  Interfaces are common such as steering wheels on cars
or typewriters on keyboards.  We don't have to understand how a
combustion engine coverts fuel into energy and then applies that
energy through the transmission to the wheels in what we know
as a car.  We just get in, start the car, and before we know it we're
down the highway, concentrating on how we can use this object
we're driving and the map or directions objects we have to get us
to our destination.  So it's natural for us to objects in programming
just as in day-to-day life.

As far as which one to use, sometimes you can choose and sometimes
you can't.  If you're using someone else's module this may be determined
for you, but if you are implementing a module you might want to give
this some thought.  Certainly larger, built-to-scale applications would
benefit greatly from an object-oriented approach.  But if it's a script that
you'll use to save you a half an hour of selective text editing you might
decide that even arranging your code in the form of a module is too
cumbersome.  I think Steve's point the other night was valid in that
when you start passing alot of data structures as arguments into your
functions you might want to see if it wouldn't be better to create some
class definitions.

Food for thought...

Rob

"James W. Sandoz; (BIO;FAC)" wrote:

> > I think the procedural interface is easier to read.  Let find out what
> > the rest of you think.
>
> Craig,
>         Thanks for the two scripts. I agree that the procedural format is
> easier to read and use it exclusively myself. I've never taken the
> time and effort to test drive the oo format.
>
> Is one 'better' to use than the other for more complicated things:
>         saving state?
>         directing to different pages depending on value of param()?
>         other things?
>
>         Jim
>
> Mr. James W. Sandoz, Instructor, UMBC Dept of Biol Sciences,
>                                  1000 Hilltop Circle
>                                  Catonsville, MD 21250
> voice: (410) 455-3497; fax: 455-3875; net: sandoz at umbc.edu