First of all you are dealing with a OO class, so there are even more options available.
In our case the main author created a very large module with a lot of cross dependencies, and other can't discuss it anymore with him.
To make it clearer, if Foo::Bar::_aa() is calling Foo::Blabla::_bb(), i.e. both are refactored into different modules you need to adjust the call to &_bb() too.
IF all your calls so far where ->method calls, you could try to import them into the main class Foo, before the first code is run.
This is very close to OO concepts named roles, mixins, traits , ...
But our case was more complicated, because we have also function calls.
So I convinced the maintainer to adapt a "evolutionary" low-level approach and to just move the functions in logical groups into several _Foo::Whatever "modules" but all belonging to "package Foo;" and to requiring them at compile time from the top-module (aka use without import).
Like this can freely move stuff into sub-files without fearing any conflicts (NB: there are no filescoped lexicals in this file)
This helps us to get an overview over the stable product and discuss necessary refactorizations on parts of the application. (Divide and Conquer)
The goal is of course to have proper sub-modules/classes in the end.
Of course, like already said, if your case is less complicated and all your calls are ->method calls, try as I told you and import _aa() from Foo::Bar into Foo::
Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice
In reply to Re: Breaking up a big module (low tech require same namespace)
by LanX
in thread Breaking up a big module
by talexb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |