On Sat, 4 Oct 2003 17:09:10 -0500, Eric Wilhelm wrote: >[snip] > 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.
Agreed. Get the interface to be the way you want it, both in the short run and the long. Then design the internals to meet the demands of the interface. (And getting the interface first enables you to write tests before designing the internals.) > 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. > The way I think of it is that the subroutines in the "submodules" only *become* methods when they're called in connection with that single blessed object. (I put "submodules" in quotes because it appears that they are packages sitting *besides* Drawing.pm rather than under it in an inheritance hierarchy -- notwithstanding the fact that they're beneath Drawing.pm in the directory structure below.) > 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.)) > Okay. > 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!) > An oft-heard complaint! jimk
