> The following was supposedly scribed by
> Mark Stosberg
> on Saturday 04 October 2003 02:06 pm:
>While this is certainly more explicit, it also means that every time
>you create or rename a shared routine, you have to declare and at least
>two places. Perhaps being explicit is it's own reward. I know I've found
>that maintaining export/import interfaces between highly related modules
>to be cumbersome at times.
>
>I can't see I have a better pattern to suggest for this case, rather
>it's a question I've run into myself and haven't fully resolved.
I think this is my real issue as well. Drawing.pm contains standard methods
for creating a new drawing, and adding elements to that drawing as well as
load and save functions. But those need to be moved because I've already got
loaddwg,savedwg,saveimg,saveps, and savegzip (which is quite handy. btw,) all
of which are called from one pair: load() and save(). It also contains
query methods.
Drawing/Manipulate.pm contains Move, Clone, Rotate, Mirror, and Copy (which
just calls Clone and then Move) and also has a set of groups-of-entities
methods (GroupMove, etc) which call the single-entity method for each entity
in the list (and the single entity method handles any entity by calling the
appropriate function from a hash of functions ($movefunc{pt} vs
$movefunc{pts} and $rotatefunc{ang} vs $rotatefunc{pt} and etc.)
Sorry to get into so much detail, but the gist of it is that it is a complex
problem set which is simplified by providing a single program interface for
the manipulation of any entity. The submodules get the same benefit out of
the current setup as the main program, i.e. Manipulate.pm can call methods
from Calculate.pm and Finite.pm simply by using Drawing.pm (and calling the
methods with the object, of course.) Since the object is blessed into only
one class, all of the methods need to be in the Drawing package, and really
don't have any business being anywhere else.
Now, about the relations between these packages:
the structure is like this:
Drawing.pm
Drawing/Manipulate.pm
Drawing/Defined.pm
Drawing/Calculate.pm
Drawing/Defined.pm
All of these declare themselves as "package Drawing", and the idea is that all
of the accessor methods become available (not exported) to main with simply
"use Drawing". Drawing.pm then contains "use" statements for all of the
sub-modules.
Drawing/Defined.pm contains all of the package global variables, which are all
exported, so each sub-module simply needs to say: 'use Drawing;' and 'use
Drawing::Defined;' This allows each file to ask for the constants without
having to say $Drawing::pi (which is quite tedious.) It also allows each
submodule to utilize the other methods (which makes them less dependent on
the data structure (which is already showing itself to be a really good
thing, because the data structure is wrong.))
I thought I might get some insight from some of the larger, more complex
modules (CGI came to mind, but alas, it is one HUGE file!)
Anyone know of an example of modules which are more spread out, but intended
to be accessed via one "use" statement? I'd like to keep each file to around
1000 lines or less.
Thanks,
Eric
P.S. I'm not sure if the CC method of replying is automatic or not, but I'm
subscribed to the list, so I'm getting two copies of everything.
--
The opinions expressed in this e-mail were randomly generated by
the computer and do not necessarily reflect the views of its owner.
--Management
