Writing a module comprised of several files?

[Andrew Crabb]

I'm making a module that I'd like to put into CPAN eventually. The code
does not lend itself to being in one file - for instance, there is a
data dictionary 2,000 lines long that seems it should be in its own
file. Also I'm trying to make it as OO as possible, and there are
subclasses that have no real utility outside of the context of being
used in the main module. So they're extra files, too.

Question: Say my module is called Image::Munge. So my main file is
called Image/Munge.pm. Where do I put the other files - in
Image/Munge/UtilityFile.pm etc? And if my module (class) Image::Munge
uses a utility class UtilityClass, it'd be called
Image::Munge::UtilityClass right? And its file would be
Image/Munge/UtilityClass.pm. But this utility class is not useful on
its own - can I prevent it from being 'visible' so that people do not
inadvertantly try to use it?

Hope I've made this as clear as mud.
Andy

 

[Ben Morrow]

Question: Say my module is called Image::Munge. So my main file is
called Image/Munge.pm. Where do I put the other files - in
Image/Munge/UtilityFile.pm etc?

That's a good place, yes.

And if my module (class) Image::Munge
uses a utility class UtilityClass, it'd be called
Image::Munge::UtilityClass right? And its file would be
Image/Munge/UtilityClass.pm. But this utility class is not useful on
its own - can I prevent it from being 'visible' so that people do not
inadvertantly try to use it?

Nope. What you can do is put

=head1 NAME

Image::Munge::UtilityClass - internal helper for Image::Munge

=head1 SYNOPSIS

No public interface.

=head1 DESCRIPTION

This is a helper class for Image::Munge. Do not use it by itself.

=head1 AUTHOR

Copyright (c) 2004 Andrew Crabb <[email protected]>

=head1 SEE ALSO

Image::Munge

=cut

in the file. People'll get the message .

Ben

 

[Anno Siegel]

I'm making a module that I'd like to put into CPAN eventually. The code
does not lend itself to being in one file - for instance, there is a
data dictionary 2,000 lines long that seems it should be in its own
file.

That should probably go in a file by itself, yes. It is quite common
for Perl modules to consist of multiple files. CPAN has the notion
of "distribution" to support this.

Also I'm trying to make it as OO as possible, and there are
subclasses that have no real utility outside of the context of being
used in the main module. So they're extra files, too.

That could be taken as a reason to keep them with the main module,
but you can separate them out as well.

Question: Say my module is called Image::Munge. So my main file is
called Image/Munge.pm. Where do I put the other files - in
Image/Munge/UtilityFile.pm etc? And if my module (class) Image::Munge
uses a utility class UtilityClass, it'd be called
Image::Munge::UtilityClass right? And its file would be
Image/Munge/UtilityClass.pm.

That's how it's usually done. Once the main module "splits off"
support modules, create an additional directory named like the main
module minus ".pm" and put the auxiliaries there.

There is no technical reason for this, it is a mere convention.
Unlike exporting modules, for classes there is no connection between
their name and the file they are loaded from.

But this utility class is not useful on
its own - can I prevent it from being 'visible' so that people do not
inadvertantly try to use it?

Ben Morrow (?) has answered this already. Put it in the documentation.

Anno