ah, i see. in this example that i cooked up to demonstrate the problem it is not used. in my real program, it is.

the base class has login and password info that all the subclasses use. the base class also has a login method.

the effect i was trying to achieve was to only have to pass the data (login/password) once and have it stored in a core object from which all the derived objects inherited not only its methods, but object data. does that violate OO principles?

In your situation I might store the login and password information in global variables in the base class. You can even be clever about it and have the constructor take those globals as default values, but allow someone to override it.

An alternate approach is to use a has-a relationship. In that case Foo::Bar would not inherit from Foo, but would have a property that was an object of type Foo, and would have a login method like this:

sub login {
  my $self = shift;
  $self->{base_obj}->login(@_);
}
[download]

Thanks.. where can I find out more about the has-a relationship? I don't see it in Conway's _Object Oriented Perl_.

Well, I modified it to use a has-a relationship (I believe) but now I am violating my original desire to only have to pass the hash once, i.e. I will have to pass it for each class I create.

As far as your first suggestion, I am turned off by the use of global variables that look like they ought to be object properties. (= Do you think this is still a better way than my original design?