Re^3: Altering the inheritance path of an object

I would suggest creating an empty subclass then:

package Test::It;
our @ISA = qw(Package::Under::Test Utility::Subs);

1;

# ... later, in another file
my $under_test = Test::It->new(...);
[download]

This way any method is first searched in the Package::Under::Test's hierarchy and only then in Utility::Subs.

Comment on Re^3: Altering the inheritance path of an object Download Code

Replies are listed 'Best First'.
Re^4: Altering the inheritance path of an object by locked_user sundialsvc4 (Abbot) on Sep 28, 2012 at 12:16 UTC
For my (possibly unrelated ...?) purposes, it would need to be being able to build a more isolated test case situation, especially for adding instrumentation to an existing, complex but poorly-designed class structure ... without significantly changing the crufty old code, if at all. I have noticed that heavily class-based code over time can wind up having a lot of “side effects,” for lack of a more proper term, which can make it difficult to deduce exactly which code-path is being taken. And, when you don’t yet really know whether any particular one of those paths are or are not reliable, that’s a big deal, at least in my situation. (I mostly deal with legacy code ... eight years old or more ... stuff that stinks but drives businesses.) I don’t want to “hijack” this particular thread into that direction, though, but I’m interested.

Replies are listed 'Best First'.

Re^4: Altering the inheritance path of an object
by locked_user sundialsvc4 (Abbot) on Sep 28, 2012 at 12:16 UTC

For my (possibly unrelated ...?) purposes, it would need to be being able to build a more isolated test case situation, especially for adding instrumentation to an existing, complex but poorly-designed class structure ... without significantly changing the crufty old code, if at all.

I have noticed that heavily class-based code over time can wind up having a lot of “side effects,” for lack of a more proper term, which can make it difficult to deduce exactly which code-path is being taken. And, when you don’t yet really know whether any particular one of those paths are or are not reliable, that’s a big deal, at least in my situation. (I mostly deal with legacy code ... eight years old or more ... stuff that stinks but drives businesses.) I don’t want to “hijack” this particular thread into that direction, though, but I’m interested.