There aren't any technical issues in using one file for methods, one for
constants, one for helper functions etc but it would be a bit of a surprise
to anyone who is used to a strong correspondence between file names and
package names.
That said, having a single package so full of stuff that you need to split it
into sub files is often an indicator that you're doing way too much in one
package anyway. It's possible you could benefit from mixin classes. That is
classes which contain only methods and these methods make very few
assumptions about about their $self object. So you'd have a Drawing::Movable
class which implements Movement methods. You can then do something like
package Drawing::Square;
@ISA = qw( Drawing::Shape Drawing::Movable Drawing::Copyable );
The key is dividing your methods into 2 classes, those which _must_ fiddle
directly with the inside of the object and those which can do the job just
using the public interfaces. The second group can often be split into mixin
classes.
As for the Exporter difficulties if you export lots of stuff from one package
and you also want to export the same stuff from another you can do
package Drawing;
sub import
{
Drawing::Constants->export_to_level(1, @_); # exports the constants to main
}
This allows you to export the symbols from Drawing::Constant when somebody doe
use Drawing;
Alternatively, if you want to export symbols from a variety of sub packages
you could do
@EXPORT = (@P1::EXPORT @P2::EXPORT, @P3::EXPORT);
rather than having to maintain a duplicate list of symbols.
F
On Saturday 04 October 2003 16:59, Eric Wilhelm wrote:
> Hi,
>
> I'm working on a module which will eventually be CAD::Drawing
>
> Currently, it is named <place where I store modules>::Drawing and the
package
> is declared as simply "Drawing".
>
> I've run into a wall with my original data structure and have seen a much
more
> flexible and expandable way to do things, so I will be rebuilding the entire
> module and its children.
>
> The sub-modules are currently stored under Drawing/*.pm and they all declare
> their packages as "Drawing". These modules contain methods and helper
> functions/constants. For example, Drawing/Manipulate.pm contains the
> functions Move, Copy (and lots of other goodies.) It would not work as a
> standalone and is not intended to ever be use'd by main. There is also a
> file Drawing/Defined.pm which exports a pile of constants, but these only
get
> exported to Drawing.pm and never show up in main (as intended.)
>
> I've seen the use of @ISA in perltoot, and it looks like this would work,
but
> it does not seem like inheritance is really what I'm doing (since the
> sub-modules aren't really base classes (none of them have (or could have)
> constructors.)) If it didn't amount to so many lines, all of the functions
> could really be contained in one file (but this makes it hard to edit and
> navigate.)
>
> Is this overloading of my own namespace the right way to go, or should I be
> using some more rigorous method? I imagine that the entire distribution
> could eventually be rather complicated, so I'd like to start down the path
to
> robustness with this next revamp.
>
> Thanks,
> Eric
> --
> "It is a mistake to allow any mechanical object to realize that you are in a
> hurry."
> --Ralph's Observation
>
>
