in reply to Import module code from external files?
What are you trying to accomplish?
From a technical standpoint, if you have memory constraints... there are better solutions.
From a maintainability standpoint, you'll have to perform some clever hacks if you want to get access to the hidden lexicals.
If your class is too large for your taste, it probably does too much.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Import module code from external files?
by z_mikowski (Initiate) on Feb 17, 2010 at 23:12 UTC | |
Memory isn't too much of a concern -- although we are running in a mod_perl2 environment, we only have 5 child processes on a 12GB machine. Startup time isn't too important either (see mod_perl2). Runtime is. The module represents the business logic layer (the Model) for a web app. Thus it glues together multiple db objects that need to be coordinated for hierarchy and user access, like accounts-to-items, account-to-files relations, etc. So the logical intent is fairly ok (see the POSIX modules as an example of similar grouping). Much of the verboseness arises from quite a few complex sql queries that are quite long, and for readability reasons, we want to keep them in the file. So the module gets big; around 2000 lines. Maybe refactoring the class hierarchy is the right thing to do, but there really isn't time to consider that, or move to Moose, at present. Besides, Moose does a lot of the same stuff "under the sheets" with "roles", I'd bet. I tried the "require" trick, autoloader (shudder), using globals (shudder), Mouse, Filter::Macro, and finally Export with a param list. The last one seems to be a winner; it's only a little bit magical, and its all "real" perl -- all modules pass the perl -cw test. The import and exporter stuff takes up about 20 lines per "split" file but I can write methods there almost exactly as in the main file. The script
The Core Module
The File with Additional Subs
| [reply] [d/l] [select] |