Modules (i.e. ".pm" files containing Perl code) and packages (i.e. namespaces that subs and variables can be defined in) are two different things. There is no rule that says you must keep their names aligned.
However, when you do align their names, certain Perl features work in your favour - for example, the use statement. use Foo::Bar is defined to load the file Foo/Bar.pm and then call the import method in the Foo::Bar package. This feature is super-handy when the Foo::Bar package happens to be defined within the file Foo/Bar.pm; less so when it isn't.
If you know what you're doing, and are aware of the order in which Perl processes things, how use works, etc, then it's sometimes possible to break the alignment in useful ways. For example, keeping several small packages in the same file can make sense - it will improve load speed, they can share lexical variables, etc.
But for the most part, unless you have a specific reason not to, you should try to keep package names and module names aligned.
package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
| [reply]
[d/l]
[select] |
Thank you for your response.
The modules I used today have something bad. I thought It was because the names of the module and the name of the file are not aligned.
When I use them from a command line script, everything works fine.
But if I use them within a Dancer's (the CPAN module "Dancer") application… it is a big mess. Many variables "become" suddenly undefined…
Note : these modules have been written in a hurry by some developers that don't respect good pratices (no "use strict", no naming conventions for variables or functions…).
So I use these modules through "system()" (that is, in a totally separated environment)… It's really bad, but, at least, it works…
Well, it is something else. I'll try to find out if I have some time.
Bets regards
Denis
| [reply] |
This piqued my curiosity. What do you mean, you "use these modules through system()?" Do you just call system("perl MyModlue.pm")? Are you quite sure this "module" is actually a module, in the sense that in defines a handful of subroutines or perhaps an object class, either way a bunch of code that doesn't do much until you tell it to? Or is it really a full fledged script that you actually run, maybe as a part of a larger system or maybe not, but a script nontheless?
When I think module, I think abstraction layer. For example, an example of modules that you could write for some project are:
- a socket factory, which creates IO::Socket::INET objects to connect to a range of servers,
- a simple object class that wraps around IO::Select, which reads from as much sockets as possible (i.e. all sockets that have data for me), remembers which sockets it took input from, and then hands that input back to my main code. More than than, as it reads the input from a socket, it already molds it into a form that will be easy to work with in the main code. Later on, the object will be able to send meaningful responses back to those sockets. It will also close connections that are no longer needed.
- a module that processes the input data, stores relevant information in a log file, and returns a list of results
There happens a bunch of other things "under the hood", but in essence this way of working allows my code to kinda look like this:
use strict;
use warnings;
use SocketFactory;
use IoSelectWrapper;
use InputHandler; # all of these could use better names... ;)
use More::Stuff;
# ...
my @hosts = More::Stuff::get_hostnames();
my $sock_fac = SocketFactory->new;
$sock_fac->connect( @hosts );
my $io = IoSelectWrapper->new( $sock_fac->sockets )
main_loop($reader);
sub main_loop {
my $io = shift;
my $handler = InputHandler->new;
while ( defined(my $input = $io->get_next) ) {
$handler->add( $input );
if ($io->is_complete) {
$io->reply( $handler->handle );
}
}
}
This is very much a simplification, but what's relevant here is that the main code is easy to read. From top to bottom, it tells Perl to get the hostnames, connect to them, wrap an IO abstraction layer around those connections, and enter the main loop. Inside the main loop, create an input handler, get a chucnk of input from the IO wrapper, and feed that input to the handler. When the IO wrapper says it has collected a complete set of input chunks, tell the handler to do its work and hand the result back to the IO wrapper. Then read the next chunk of input until there's nothing more to read.
The (imaginary) fact that InputHandler.pm is almost 1000 lines of code, IoSelectWrapper.pm is just over 400 lines, SocketFactory.pm about 100, and More::Stuff is actually 6 different files totalling to around 6000 lines, is completely invisible from the main code. The main code is short, simple, and abstract. All the gory details of creating sockets, connecting to other servers, maintaining those connections, reading data, parsing data, processing that data, and logging the act of processing, are neatly hiddden in their own relevant modules.
Note that none of these modules can run stand-alone. They're all part of a bigger system. IoSelectWrapper, for example, wouldn't have anything to read from without More::Stuff kindly opening connections for it, and InputHandler can't do a thing until IoSelectWrapper begins spitting out data. Also note that none of these modules do a thing until the main code tells them to. IoSelectWrapper just sits around, staring at its nails, only to occasionally read from a few sockets once every iteration. InputHandler is standing in the corner, soaking up everything it sees until its told to process all of that, and while it's processing, IoSelectWrapper can't even get a cup of coffee because this program doesn't use threads or call fork, so everybody in the room waits until InputHandler comes back with its results.
Most of these modules use other modules in turn. For example, SocketFactory will use IO::Socket::INET at the least, IoSelectWrapper surely uses IO::Select and what-else-you've-got. It's likely that they're both built using Moose or Moo or a similar framework.
To come back to my point, when I think module, I think long wall of code, doing all sorts of useful things for me, such that I don't have to bother how it does it. I think subroutines or methods that I will pump data into and that will throw something back at me, and possibly I think of import lists or tags, if the module is written to export stuff. Which my modules are hardly ever — I'm an OO junkie.
I think all that when I think module. I definitely don't think system(...). So I'm wondering, are your "modules" modules? Or are they stand-alone scripts that nevertheless could be part of a bigger system?
| [reply]
[d/l]
[select] |
use HR; # using your example
it checks all the directories in @INC for a file named "HR.pm" and isn't going to look in "MyModule.pm"
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
| [reply]
[d/l]
[select] |
Hello,
Thank you.
I know. That's why I use :
use MyModule;
That way, Perl finds the file "MyModule.pm".
But the the module's name is "HR" (as declared after "package"), not "MyModule".
I think that it messes up something.
I may be wrong.
What do you think ?
Thank you.
| [reply]
[d/l] |
| [reply] |
What exact problems do you have with these modules?
use just makes <ModuleName>.pm file from @INC be evaluated at the beginning of program (BEGIN{} block). <ModuleName>.pm can define any packages it wants to, but it's not a common way of writing modules.
So, if MyModule.pm contains this code:
package NotMyModule;
sub function { 1 }
you can use its functions in your program by calling them by package names, not by the name of the file:
use MyModule;
NotMyModule::function;
By the way, one file can define more than one package, thus making fatpacking modules in an application possible.
Sorry if my advice was wrong.
| [reply]
[d/l]
[select] |
Hello Aitap,
I just add a new message that describes the problem.
But I have not many details to give. I though that the problem came from the naming convention... I did not look further.
I'll look tomorrow, if I have some time.
Regards
Denis
| [reply] |
So long as you remember to refer to things using the correct package name (HR::myFunction) rather than the file name (MyModule::myFunction), the only technical issue is that symbols exported by the package won't work automatically. If it exports anything, you'll have to manually call HR->import; after you use MyModule; because the automatic call to MyModule->import; won't do anything.
Even though it doesn't cause technical problems, it does tend to cause major usability and maintenance problems, so, as a general rule, it shouldn't be done except in very limited circumstances. A package named HR in a file named MyModule.pm is not one of those circumstances. | [reply]
[d/l]
[select] |
I am having just as much trouble figuring out what your question is as you
are having trouble writing said question!
A project for me may have say 15 project specific modules. I think this is
on the order of your project?
I think up a TLA (Three Letter Acronynm), like "TDP", "This Darned Project"
that describes the project. I use that capitailzed
TLA in all file and package names related to
the project.
I make a directory like "../TDP/TDP_LIB". The source code (.pl) programs go
into ".../TDP". All of the .pm modules for that project go into ".../TDP/TDP_LIB". I name all
of the .pm module file names with a name like: "TDP_parsing.pm". That same file name
is used within the .pm module as the package name: package TDP_parsing;
A program that uses project specific parsing from TDP, might code as:
uselib "../TDP/TDP_LIB"; #some path to TDP project specific modules
use TDP_parsing;
I haven't used the double colon, "::" for paths and package names. All of my packages have
an "O/S legal" file name. I usually make the package name to be the same as the O/S name
for that file. A package name like "pm::abc" does not meet that requirement. I
personally would make that "PM_ABC" because it eliminates one level of directories.
In summary, there does appear to be some ambiguity when using the double colon "::".
| [reply]
[d/l]
[select] |
It is my understanding that the names should agree because Perl looks for module-files by matching the file name. It reads whatever it finds, of course expecting that the desired package-name will be defined thereby.
However, the formal purpose of the package directive is to introduce a namespace, and once Perl has been cajoled into reading a source-file, it will of course recognize all of the package (namespace) names found therein. Sometimes there are very good, even compelling, reasons to do just that ... for instance, when you are defining grammars for Parse::RecDescent (and I don’t know offhand if it is strictly necessary ...), or when you simply have a group of classes that you know will always be used together to help one another out.
| [reply] |
