in reply to Getting parent class data
I would suggest starting like this:
This gives you lots of flexibility. Then, you have the best of both worlds: you can define a convention, and, in true perl fashion, you can define how to do something different from convention. For example, someone may want a bunch of apps to share the same logger class, so they just override logger_class, and you continue unconcerned about the change. Your default could even do much what you are doing already (although you're using @_isa_parts and $_isa_parts - two entirely different variables...):my $LoggerClass = $self->logger_class();
This also gives you some more flexibility where you can return an object instead of a class, or you can change the default in some other way. Or you can require the desired class to ensure it's loaded, ... whatever. It's localised. Though, if you want that extra flexibility, I'd suggest allowing the logger class to be passed in and possibly cached.sub logger_class { ref(shift) . '::Debug'; }
This would then allow the constructor to an object set its own logger class on an object-by-object basis. Or allow a package to set its logger class by overriding and passing in the new value (to allow the initialisation to occur):sub logger_class { my $self = shift; my $set = 0; # was a (new?) class passed in? $self->{__PACKAGE__ . ':logger_class'} = shift and $set++ if @_; # if we don't have one, construct the default. unless (exists $self->{__PACKAGE__ . ':logger_class'}) { $self->{__PACKAGE__ . ':logger_class'} = ref(shift) . '::Debug'; $set++; } # if it changed, do any configuration needed. if ($set) { # load the class, etc. } # done - return it. $self->{__PACKAGE__ . ':logger_class'}; }
Lots of alternatives. Depends on how overboard you wanna go with this newfandangled "OO" fad ;-)# in some other package... sub logger_class { my $self = shift; $self->SUPER::logger_class('Some::Shared::Package::Debug'); }
|
|---|