Instead people usually just document classes as being private, and don't rely on language functionality to enforce it.

• perlboot Beginner's Object-Oriented Tutorial
• perltoot Tom's Object-Oriented Tutorial
• perltooc Tom's OO Tutorial for Class Data
• perlobj Objects
• perlbot Bag'o Object Tricks

Plus, if you are on the lookout for a nicer OO syntax in Perl, rather than building it all by hand, you might want to look at Moose.

I can understand why you want to create them, sometimes inner classes are an elegant way of solving a problem. In languages like Java, C++ and Python it is common practice. Java even has four(!) different types of inner classes and they can make your code a lot cleaner. In Perl just about anything is possible. Although it is common practice to have one class per file, it is not mandatory. Take a look at Inner Classes for ideas.

Cheers,

Harry

# File: Frobnicate.pm

use warnings;
use strict;

package Util;
.
.

package Frobnicate::Bar;
.
.

package Frobnicate::Foo;

our @ISA = qw/Frobnicate/;
.
.

package Frobnicate;
.
.

1;
[download]

• All classes (packages) are visible to each other.
• Only Frobnicate is accessible (& thus available as a superclass) externally.
• Frobnicate::Foo subclasses (and thus has a 'relationship' with) Frobnicate.
• Frobnicate::Bar has no 'relationship' with Frobnicate

Update:

The most apposite & absolutely correct) observations of both GrandFather & dsheroh have, between them, served to most ably demonstrate the...

• Voracity of my sig here on the monastry
• Correctness/validity of the (sometimes self-imposed) coding standards (&/or conventions) to which I have worked - my posting was purely experience based

Given:

use warnings;
use strict;

package Frobnicate::Bar;

sub new {
    my ($class) = @_;
    return bless {}, $class;
}


sub sayWhat {
    my ($self) = @_;
    
    if (ref $self) {
        print "I'm a ", ref $self, " method\n";
    } else {
        print "I'm a ", __PACKAGE__, " function\n";
    }
}


package Frobnicate::Foo;

our @ISA = qw/Frobnicate/;

sub new {
    my ($class) = @_;
    return Frobnicate::new ($class);
}


sub sayWhat {
    my ($self) = @_;
    
    if (ref $self) {
        print "I'm a ", ref $self, " method\n";
    } else {
        print "I'm a ", __PACKAGE__, " function\n";
    }
}


package Frobnicate;


sub new {
    my ($class) = @_;
    return bless {}, $class;
}


sub sayWhat {
    my ($self) = @_;
    
    if (ref $self) {
        print "I'm a ", ref $self, " method\n";
    } else {
        print "I'm a ", __PACKAGE__, " function\n";
    }
}


1;
[download]

consider:

use strict;
use warnings;
use noname1;

Frobnicate::Bar->new ()->sayWhat ();
Frobnicate::Foo->new ()->sayWhat ();
Frobnicate->new ()->sayWhat ();
Frobnicate::Bar::sayWhat ();
Frobnicate::Foo::sayWhat ();
Frobnicate::sayWhat ();
[download]

which prints:

I'm a Frobnicate::Bar method
I'm a Frobnicate::Foo method
I'm a Frobnicate method
I'm a Frobnicate::Bar function
I'm a Frobnicate::Foo function
I'm a Frobnicate function
[download]

So, exactly what is hidden from the calling code exactly?

btw, I don't condone the use of the same sub as a method and a function. Used here to reduce code peripheral to the main thesis.

---

True laziness is hard work

Only Frobnicate is accessible (& thus available as a superclass) externally.

Incorrect. Any external code which does a use Frobnicate will get access to all packages/classes within Frobnicate.pm. The relationship of "file name == package name" is purely a matter of convention. It is not enforced in any way by perl.

Let's create a module Foo.pm containing:

package Bar;

sub identify {
  print "I'm in package " . __PACKAGE__ . "\n";
}

1;
[download]

and then write a program that says:

#!/usr/bin/perl 

use Foo;

Bar->identify();
Foo->identify();
[download]

Running this program produces the output

I'm in package Bar
Can't locate object method "identify" via package "Foo" (perhaps you f
+orgot to load "Foo"?) at...
[download]

As you can see, Bar being named differently than the file it's in does not in any way reduce its visibility or accessibility to the outside world.

But don't do that in production code, of course. The reason for the convention is because use Foo giving you access to package Bar is confusing as hell, especially if it doesn't give access to package Foo.

The modern way to do OOP with Perl is to use MooseX::Declare. The official Perl docs refer to the old way (and still used, of course) of doing OOP with Perl using bless on hashrefs and so forth.

s!modern!experimental!