Honestly, all the jargon makes it a lot more mysterious than it really is but you need the jargon to talk about the subtleties of it all.

Class

a data structure blueprint and a set of subroutines that know how to work on that structure.

Method

a subroutine that knows how to work on a particular data structure.

Object

a chunk of real data that follows a blueprint and has a field in it that knows what Class it belongs to.

Instantiate

to use the blueprint in a Class to create a new, filled-out data structure.

Call

look up a subroutine by it's method name in the Class that the object belongs to.

Inherit

borrow general purpose routines from a "parent" that work on parts of your structure.

HTH. There is a lot more to it but that is a sorta ok mapping to the world you are likely to have been working in. Others, help me out if I've "translated" that in some evil way that will only hurt him later, please.

--
$you = new YOU;
honk() if $you->love(perl)

$obj->meth(@args);

and

meth($obj, @args);
[download]

So basically, don't worry about memory overhead: it's not an issue. Code performance is the more serious problem, because of the added indirection in OO architectures and added abstraction inherent in OO designs.

// Some Pseudo Code of Class Foo
Class Foo {
  Static int FooCount;
  float FooVariable;

  Static int FooInc() {return FooCount++;}
  float GetFooVar()   {return this.FooVariable;}
}
  
Foo MyFoo  = New Foo(3.14);
Foo MyFoo2 = New Foo(6.02);
[download]

We have Class Foo that has some static and normal variables. It also has static and normal methods. We instantiate this class in MyFoo with a New method and FooVariable = 3.14 and MyFoo2 with FooVariable = 6.02.

The New method also increments a Static Variable FooCounter which keeps track of how many Foo's we have running around in memory space. It does this with the Static Method FooInc(). Finally, there is a method GetFooVar() which returns the FooVariable of a specific Foo.

Now we have a memory block that contains the Foo Class along with its Static Variable FooCount = 2 and pointers to the Static Method FooInc() and normal Method GetFooVar().

There are also two memory blocks that contain the data of the Foo (one for MyFoo and another for MyFoo2). These two memory blocks also contain pointers back to the Foo Class as well as a bit more information about the Foo class. Using the class pointer and some memory offset information, they can access the GetFooVar() method. They do not have memory offset info to the FooInc() method though, because that is static and can only be called on the Foo class itself. (Probably it would be Private of course and only callable by Foo itself, but it's still Static.)

This is how I remember it, but no warantee or anything. It gets far more complex pretty quickly when you start adding things like inheritance or whatever, but I think this answers your question. Basically, one instance of Static information and methods, but each instance of the class will contain some pointer information for the class and each method it might need to call, so there will be a little extra bloat, but it should be trivial (a few bytes) compared to the size of even a single method.

By all means, please correct any errors oh compiler writing types (I don't take that class till next year).

-Lexicon

A monk on a similar quest to my own. After all the reading on Perl OO I could get my hands on, (which went far to understanding the terminology and concepts), I found when I sat down to play, much of the information made the issue far more complex than necessary to learning and utilizing Perl OO code.

Perl OO cannot be compared to Java as essentially you control the object, not a VM. This is much more fun but frought with hazards. I wish someone had provided the following code about two weeks ago, as Perl OO is much easier to understand and use from a minimalist approach rather than trying to grok all the issues at once.

Use the following bench to rotate your code changes through Tiny.pm and NotSoTiny.pm. Every keystroke change becomes immesurably more important in OO and by focusing on the effects of each keystroke your basic Perl understanding and your grokking of Perl OO will grow with it.

In the end the what where and how becomes mute, and it becomes just a variation of coding in Perl.

package Tiny;
# Filename Tiny.pm
# The Worlds Smallest Perl Object
use strict;

sub new {
   return bless { }, shift;
}

1;
-------------------------------------------------------
package NotSoTiny;
# Filename NotTiny.pm
use strict;

sub new {
   return bless { value => 'A value' }, shift;
}

sub get_value {
   return shift->{value};
}

1;
------------------------------------------------------
#! /usr/bin/perl -w
#Filname: bench
use Benchmark qw(timethese); # perl 5.6 has 'cmpthese' 
                             # which is very cool, and
                             # much more informative
                             # If you have 5.6 just
                             # s/timethese/cmpthese/g
use strict;
use lib ('./');

use Tiny;
use NotSoTiny;

my ( $roll, @roll );

my $loop = 250000; # You will want this var up here to
                   # Adjust itineratations to avoid 
                   # warnings

######  Preload Objs ###################################
# Benchmark two ways one with pre constructed objs and
# another without considering construction costs.
my $TinyObjBase           = Tiny->new();
my $NotTinyObj            = NotSoTiny->new(); 

###### SubRoutine Vars #################################
# To be completely fair do the same with the Vars for
# the subroutines.
my $TinySub;
my $NotSoTinySub; 

###### End Init ###########

system("clear");
my $loops;
for $loops ($loop)  { 
   timethese $loops, {

      ##### Subroutine Comparisons 
      TinySubPreVar => sub {
         $TinySub = Tiny();
      },
  
      TinySubNewVar => sub {
         my $NewTinySub = Tiny();
      },

      NotSoTinySubPreVar => sub {
         $NotSoTinySub = NotSoTinySub();
      },

      NotSoTinySubNewVar => sub {
         my $NewNotSoTinySub = NotSoTinySub();
      },
 
      #####  Object Comparisons
      TinyObjReused => sub {
         $TinyObjBase;
      },

      TinyObjNew => sub {
         my $NewTinyObj = Tiny->new();
      },

      NotSoTinyObjReused => sub {
         $TinySub = $NotTinyObj->get_value();
      },

      NotSoTinyObjNew => sub {
         my $NotSoTinyObjNew = NotSoTiny->new();
         $TinySub = $NotSoTinyObjNew->get_value();
      },
   };
}

sub Tiny {
   return;
}
sub NotSoTinySub {
   return 'A value';
}
[download]

coreolyn