Ctrl-z writes:

So, theorhetically, is manipulating an objects inheritence based on how it is currently being percieved, a worthwhile cause for meditation?

Without intending to, you have pointed out the exact reason why so many people new to Perl have difficulty when understanding the effects of modifying @ISA.

You say "manipulating an object's inheritance". The only way to manipulate an object's inheritance is to bless() it into another class:

my $object = Class1->new;
bless $object, 'Class2';
[download]

Manipulating @ISA does not change the inheritance of an object. It changes the implementation of the class. The effect of this is that all objects that are blessed into the class suddenly inherit a different set of methods. To this end, we find chaos. Perl attempts to improve the performance of method invocations by caching the results of method lookups. These cached results become incorrect when @ISA is alterred. Also, from a code re-entrancy requirement, since changes to @ISA are global, it would be very difficult for two sections of code that had different 'perspectives' to access the same set of objects at the same time.

You have a good point in your node -- the perspective of the programmer, and the requirements for the project dictate the class names that are decided upon. These names may be inaccurate to a programmer with a different perspective, or a project with a different set of requirements.

The most common solution to this problem is the class hierarchy. The Employee class that you refer to above would perhaps better be named Acme::Payroll::Employee. This additional context specifies the context under which the class should be perceived from.

Ctrl-z writes:

Of course, an Employee may also be a Musician, Artist, Trainspotter (in their spare time), or a Father, Husband, Buddy, or a Jerk, Hero, Nondescript-Bystander. There is no little tree diagram that can display this, because largely it is a matter of perspective. Once you have the perspective of the "viewer" (perhaps the user, or another object) then the tree of inheritence can organise itself. Its not the One True Tree of the Employee class - its just a perspective.

In English, we say 'Mark is an artist.' or 'John is a musician.' From a design perspective, however, 'Artist' is a professional role. The question "Is there an artist in this room?" is programmatically similar to:

my @people_in_room = grep {$_->isa('Person')} $room->contained_objects
+;
my @artists_in_room;

for my $person (@people_in_room) {
    push(@artists_in_room, $person)
        if grep {$_->isa('Artist')} $person->professional_roles;
}
[download]

The relationship between real life objects is quite sophisticated, and is often not a case of inheritance. In the programming domain, object models rarely ever need to be as complicated as they are in real life domain. Simple problems call for simple solutions.

UPDATE: Abigail-II is insistent that the method cache problem is not an issue, since it is fixed in recent versions of Perl. Although he could have been more polite about it, I accept his criticism, and have striken out the offending sentence. Cheers!