> The following was supposedly scribed by
> James E Keenan
> on Saturday 04 October 2003 05:49 pm:
>Eric's description seems to be more bringing code from the side rather than
> from above/below, so that's why I'm inclined to advise an Exporter-approach
> rather than an OO. We would probably have to know more about the future
> scope of his project to make a better judgment.
The project is going to be limited mostly to the realm of 2D geometric drawing
and modeling (currently aimed at batch processing.)
I'm not sure that it is really "pulling code in from the side". The
submodules would really not be usable as anything else, so what I'm trying to
do is simply break the code into organizational elements, not different
packages. If everything were to get dumped into one file, it would have the
same heirarchy in terms of compiling and namespace, but it would totally
change the editing and storage. I'd also like to structure things somewhat
as "bolt-on" due to the C library requirements for some of the load/save
functions (this would need to be some kind of installation option, but I
haven't tackled that issue yet.)
Were I to set out on a path to build a 3D module, it might justify
parent-child class relationships, but 2D code does not easily extend any
further than 2.5D (remaining parallel to the xy plane, but having a
z-coordinate.)
With this in mind, do I need to bother with exporting and creating a
different package name for every file?
--Eric
--
"Matter will be damaged in direct proportion to its value."
--Murphy's Constant
