Re: Altering the inheritance path of an object

[Athanasius]

in reply to Altering the inheritance path of an object

Is this what you mean?

 1:07 >perl -MData::Dumper -E "say join(q[, ], @Data::Dumper::ISA); @D
+ata::Dumper::ISA = ('fred', 'wilma'); say join(q[, ], @Data::Dumper::
+ISA);"
Exporter
fred, wilma

But why would you want to do this?

Update: Sorry, I saw “class’, missed “object”. I apologise for the noise. But I’d still like to know, why do you want to do this?

[citromatik]

I work with a complex inheritance layout and have the impression that some classes can gain some functionality by inserting a new SUPER class (without breaking the code). But I prefer to work at the "test level" instead of changing the inheritance path in the classes' files. This way, if I am proved wrong, I don't have to change anything (and there is no risk to leave the classes with a wrong inheritance path)

.

[sundialsvc4]

It sounds like you are pursuing a rather intriguing testing scenario with regard to a complex legacy application.   I also have experienced that complex and sometimes interlocking inheritance-paths can create situations that are extremely difficult to test with any confidence that the testing scenario that you’re trying to set up actually matches the reality of the application.   Never really found a good way to approach it, and I didn’t think of this.   I’d love to read a Meditation about what you are doing and/or about the issues that you’re dealing with now, someday soon ...

[Dallaylaen]

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(...);

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

[sundialsvc4]

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.