For clarity, instance variables are defined within methods and while in many classes they are all defined in the constructor (method) this is not always so.

Most OO Perl programmes are today written using Moose, Moo, Mouse, etc.

I'm sure that many are - but "most"? Do you have any data to back this up? I've been using Moo on and off for a couple of years and have just returned to it in the last week or so. Building a class using the current docs I find that my version of the module is now out of date but that doing the upgrade requires a whole heap of work because of all the (mostly new) dependencies which also serves to reinforce how heavy it is, despite a contrary statement of its aims.

We don't all write daemons or other persistent code where startup time is not a consideration. We don't all have swathes of memory at our disposal to fill with cascades of module dependencies. We don't all have deployment environments where module upgrades can be made with impunity. At least, not all the time :)

The "modern" OO module frameworks such as these are a boon for sure, but they are not a panacea. And while they are probably the simplest, easiest introduction to Perl OO for java programmers like the anonymous OP, if they hide what's going on under the bonnet (or the programmer never thinks to look) the lack of appreciation of the OO core will always hold the programmer back.

Those of us who can remember the introduction of OO into Perl will have been writing such bare-bones code for a decade or more. Many of us still do. While the resulting source may have a little too much boilerplate for some tastes, it will be fast, light and portable.

In summary, it's horses for courses. Learn both approaches, take the best from each and choose from that experience which to apply in relevant situations.

I'll get off my soapbox now. Thank you for listening.

For clarity, instance variables are defined within methods and while in many classes they are all defined in the constructor (method) this is not always so.

I guess I should have said: Mostly, instance variables are defined within a constructor, or within a method called (directly or indirectly) by a constructor. But in some (rare?) cases, instance variables are recycled (via constructors and destructors) from an object pool created in a BEGIN block and stored in a class variable (array or hash) at package scope. (Am I still missing something here?)

I'm sure that many are - but "most"? Do you have any data to back this up?

No, that was merely my impression from reading PerlMonks! But the point I wanted to get across to the OP was this: If you come to Perl from an OO language like Java or C++, Perl’s core OO features may appear underwhelming. But Moose and related modules are in common use, and provide many of the OO features you were expecting. So by all means learn how OO works in Perl, but don’t judge “Perl OO” by its core mechanisms alone.

I'll get off my soapbox now.

The issues you raise are worth discussing, and your points are well made.

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

Moo is pretty light and is fairly suitable for most non-swaths-of-RAM-situations. I've used it plenty for small utility scripts when I need OO. The slight tradeoff in speed is definitely made up for in readability.

Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Could you provide a simple example of how one would use a class variable in Perl?

Sure!

#! perl
use strict;
use warnings;

package Widget
{
    my $count = 0;

    sub new
    {
        my ($class, @args) = @_;
        my  %self = @args;
        ++$count;
        return bless \%self, $class;
    }

    sub DESTROY   {      --$count; }
    sub get_count { return $count; }
}

package main;

my $w1 = Widget->new(name => 'foo', value => 42);
my $w2 = Widget->new(name => 'bar', value =>  7);
my $w3 = Widget->new(name => 'baz', value => 12);
printf "Now there are %d Widgets\n", Widget::get_count;
undef $w1;
printf "Now there are %d Widgets\n", Widget::get_count;
[download]

Output:

15:52 >perl 856_SoPW.pl
Now there are 3 Widgets
Now there are 2 Widgets

15:52 >
[download]

Is there any other way, using the code I wrote, to access the value of an instance variable with a method that did not receive the variable as a parameter?

Not that I can think of. Anyway, that’s not how it’s supposed to work in Perl.

a class variable could be defined outside the constructor but still as a lexically scoped, 'my' variable? What about using 'our'?

Using our creates a package variable, which can then be exported to other packages, or accessed directly by other packages using the $Widget::count syntax. Using my creates a lexical variable, which is scoped to the package. The rule is: use a lexical (my) variable unless you have a good reason to make it a package/global (our) variable. Update (Jan 30, 2014): See Ovid’s classic post 'our' is not 'my'.

Hope that helps,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

our %error_dictionary = ...;
our %cached_templates = ...;
sub get_template { .... check cache or store in cache ... }
sub get_error { $error_dictionary{...} ... }
[download]

If these were, my lexical, then its hard to peek inside for folks that need to ...

Being our globals, anyone who wants to peek can do so at their own risk, an know to stick with the official api for officialness

one or the other, it doesn't really matter, this is the least important type of implementation detail... but you can't go wrong with openness (our our our)

https://metacpan.org/module/DROLSKY/perl-5.15.6/pod/perlootut.pod, chromatics free book Modern Perl, Moo, Re^3: High level OOP query (internal data)