Problem

You want to inherit from an existing class, augmenting it with a few extra methods, but you don't know which data fields your parent class is using. How can you safely carve out your own namespace in the object hash without trampling on any ancestors?

Solution

Prepend each of your fieldnames with your own class name and a distinctive separator, such as an underscore or two.

Discussion

An irksome problem lurks within the normal Perl OO strategy. The exact class representation must be known, violating the veil of abstraction. The subclass has to get unnaturally chummy with all its parent classes, recursively.

We'll pretend we're a big happy object-oriented family and that everyone always uses hashes for objects, thus dodging the problem of a class choosing an array representation but inheriting from one that instead uses a hash model. (The solution to that problem is aggregation and delegation, as shown in perlbot (1).) Even with this assumption, an inherited class can't safely use a key in the hash. Even if we agree to use only method calls to access attributes we don't ourselves set, how do we know that we aren't setting a key that a parent class is using? Imagine wanting to use a count field, but unbeknownst to you, your great-great-grandparent class is using the same thing. Using _count to indicate nominal privacy won't help, since gramps might try the same trick.

One reasonable approach is to prefix your own data members with your package name. Thus if you were class Employee and wanted an age field, for safety's sake you could use Employee_age instead. Here's a sample access method:

sub Employee::age {
    my $self = shift;
    $self->{Employee_age} = shift if @_;
    return $self->{Employee_age};
} 

In the spirit of the Class::Struct module described in Recipe 13.5 , here's a more turnkey solution to the problem. Imagine one file with:

package Person;
use Class::Attributes;  # see explanation below
mkattr qw(name age peers parent);

and another like this:

package Employee;
@ISA = qw(Person);
use Class::Attributes;
mkattr qw(salary age boss);

Notice that they both have an age attribute? If those are to be logically separate, we can't use $self->{age} , even for ourselves inside the module! Here's an implementation of the Class::Attributes::mkattr function that solves this:

package Class::Attributes;
use strict;
use Carp;
use Exporter ();
use vars qw(@ISA @EXPORT);
@ISA = qw(Exporter);
@EXPORT = qw(mkattr);
sub mkattr {
    my $hispack = caller();
    for my $attr (@_) {
        my($field, $method);
        $method = "${hispack}::$attr";
        ($field = $method) =~ s/:/_/g; 
        no strict 'refs'; # here comes the kluglich bit
        *$method = sub {
            my $self = shift;
            confess "too many arguments" if @_ > 1;
            $self->{$field} = shift if @_;
            return $self->{$field};   
        };
    } 
} 
1;

This way $self->{Person_age} and $self->{Employee_age} remain separate. The only funniness is that $obj->age would only get the first one. Now, you could write $obj->Person::age and $obj->Employee::age to distinguish these, but well-written Perl code shouldn't use double colons to specify an exact package except under extreme duress. If you really are forced to, perhaps that library could have been better designed.

If you didn't want to write it that way, then from inside class Person, just use age($self) and you'll always get Person's version, whereas from inside class Employee, age($self) would get Employee's version. That's because it's a function call, not a method call.

See Also

The documentation on the use fields and use base pragmas, standard as of Perl 5.005; Recipe 10.14