Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Call Grandparent Method, Skipping Parent

by derby (Abbot)
on Jun 20, 2013 at 12:35 UTC ( [id://1039965]=note: print w/replies, xml ) Need Help??


in reply to Call Grandparent Method, Skipping Parent

At the risk of downvotes -- Yuck, Yuck and triple yuck. What beastly mis-modeling deeds would lead you down this road?

-derby

Replies are listed 'Best First'.
Re^2: Call Grandparent Method, Skipping Parent
by QM (Parson) on Jun 20, 2013 at 12:51 UTC
    Yuck, Yuck and triple yuck.
    Yes, agreed.

    I have a script XXX, written as a module that can be inherited from. A second script YYY inherits from XXX, but doesn't want to call XXX->setup. YYY does need to call the grandparent WWW->setup.

    As YYY needs other methods from both, it's not clear how to manage this generically in a large code environment, where modules are run as scripts, but may also be inherited from in the future.

    If the grandparent's name changes, or the number of intervening parents to skip changes, code will need updating. Perhaps it would be better in the grandparent's new to register some value for its children to reference, to know the name of the "interesting" ancestor?

    -QM
    --
    Quantum Mechanics: The dreams stuff is made of

      Why not refactor XXX into ZZZ (which holds everything but XXX->setup) and XXX which inherits from ZZZ and only has distinctive setup? YYY can now inherit from ZZZ as well.
      WWW (+setup) WWW (+setup) +-XXX (+setup) => +-ZZZ +-YYY +-XXX (+setup) +-YYY
        Why not refactor XXX into ZZZ...
        Yes, but the point is to avoid refactoring existing code where possible.

        The Long Story

        My team has inherited a large codebase of resource libraries. Due to the man-years required to refactor this into something that fits the use model, the team is making use of the existing codebase. (Eventually, something may replace it, or we may move on to something completely different.)

        This is a system to test real hardware, firmware, and software in multiple systems communicating with each other, the test controller, and other interested auxilliary systems. The core of the codebase is an "event loop" system that polls multiple remote systems, registers events to trigger at specific times, and registers signal handlers listening for certain kinds of responses. (Some issue with threads was apparently encountered at inception, so this is a polling system using RPC or somesuch.)

        Our current aim is to write stand-alone tests for various components and features. The base class that all tests use is capable of handling nested tests, such that with a little forethought, all tests can be run concurrently in the "event loop" system. The base class registers all nested tests, and runs through all setup methods, then all initiate methods, then all complete methods, then all teardown methods. While the execution path is not threaded, multiple events on multiple systems can occur concurrently or simultaneously (depending on the nature of the events). Properly structured tests are written as modules, which can then be used (nested) in other tests, ad nauseum.

        The point of my question was to discover a practical way to layer tests upon tests, with minimal rewriting of existing tests. Since everything is in a formal system with code reviews and releases, it is important not to go refactoring big swaths of code to add a minor bit of coverage to the suite of tests.

        I've swept a lot of details under the rug, and while there is some leeway to change direction, we can't incur a lot of refactoring time. There is a moderate but growing list of test scripts, so any global refactoring decision should be made as soon as possible.

        Ultimately, I think we'll have to refactor the big methods into smaller ones, and call into the parent(s) at a refined level to do only the bits needed, and not just rewrite a larger method (with considerable duplication). (I've probably left something out, but I'll stop here for now.)

        -QM
        --
        Quantum Mechanics: The dreams stuff is made of

      "I have a script XXX, written as a module that can be inherited from."

      Don't do that. Write a module and then write a simple script that accesses the module.

      "If the grandparent's name changes, or the number of intervening parents to skip changes, code will need updating."

      Which is why you should be using Roles instead of Inheritance, generally speaking. See Inheritance Versus Roles

      jeffa

      L-LL-L--L-LL-L--L-LL-L--
      -R--R-RR-R--R-RR-R--R-RR
      B--B--B--B--B--B--B--B--
      H---H---H---H---H---H---
      (the triplet paradiddle with high-hat)
      

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2024-03-29 12:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found