in reply to Class Inheritance Abuse. Best way to fix it?

It might not make you feel better, but you could mixin, by having the other module explicitly export methods you need. This avoids some of the problems of multiple inheritence (it lets you pick and choose which methods you want and can make things more explicit, saving time with collisions happen).

For example, drop BLL::OtherPackage from your use base list, but use it instead like this:

package My::App; use strict; use warnings; use base qw(CGI::Application); use BLL::OtherPackage qw( sub_in_other_file );
Then change BLL::OtherPackage so it exports:
package BLL::OtherPackage; use strict; use warnings; use base 'Exporter'; our @EXPORT_OK = qw( sub_in_other_file ); sub sub_in_other_file { my $self = shift; # $self would be what I expected if I didn't put this in # the 'use base' or @ISA for that matter. What an abuse. } 1;
In closing, I urge you not to guilty when you use Perl features to get your job done.

Phil

Replies are listed 'Best First'.
Re^2: Class Inheritance Abuse. Best way to fix it?
by girarde (Hermit) on Jun 05, 2006 at 21:21 UTC
    Hopefully he doesn't use BLL::OtherPackage elsewhere, and hopefully he'll remember to re-edit if he installs a new version.

    Not that I have a better idea right now. :-(

      It doesn't matter if BLL::OtherPackage is used elsewhere. The exporting code runs as many times as is required. If you say use BLL::OtherPackage qw( ... ) then an import call will occur. Period. BLL::OtherPackage is only compiled once but that's ok because you shouldn't need to keep recompiling it.

      ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊