Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Altering the inheritance path of an object

by Athanasius (Monsignor)
on Sep 27, 2012 at 15:14 UTC ( #996025=note: print w/ replies, xml ) Need Help??


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?

Athanasius <°(((><contra mundum


Comment on Re: Altering the inheritance path of an object
Download Code
Re^2: Altering the inheritance path of an object
by citromatik (Curate) on Sep 27, 2012 at 15:26 UTC

    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)

    .

    citromatik

      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 ...

      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.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://996025]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2014-10-25 02:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (140 votes), past polls