|
Re: difference between packages and module
by ysth (Canon) on Jun 21, 2005 at 05:40 UTC
|
A package is a division of the global namespace; that means you can have a global variable $foo and/or a sub named foo in one package and a different global variable $foo and different sub named foo in a different package.
A "module" is a file named according to the package it contains, so module
Foo::Bar would be in a file named Foo/Bar.pm. There's no need for packages to be modules or for a module to contain only that one package.
The term "module distribution" refers to a collection of one or more modules that get built/installed together. Sometimes the "distribution" part is left off and
it's just called "module", but it's really a different idea than a single module. | [reply] |
|
|
"...so module Foo::Bar would be in a file named Foo/Bar.pm."
As best as I can tell this is actually a file named "Bar.pm" in a subdirectory named "Foo". Can this sort of thing go on to multiple levels? Like, could we have a module named "Utterly::Completely::Foo::Barred::Up" that would be defined in the "Up.pm" file located in the "Utterly/Completely/Foo/Barred" subdirectory (of a member of @INC, I guess)?
And, is that the only place where such a module could be found, or could it also be in a file of a different name and/or in a different subdirectory?
| [reply] |
|
|
As best as I can tell this is actually a file named "Bar.pm" in a subdirectory named "Foo".
Same thing. The directory is considered to be part of the filename, really, as the distinction is often meaningless in practice, and files' actual names cannot contain forward slashes anyway, so there's no ambiguity.
Can this sort of thing go on to multiple levels? Like, could we have a module named "Utterly::Completely::Foo::Barred::Up" that would be defined in the "Up.pm" file located in the "Utterly/Completely/Foo/Barred" subdirectory (of a member of @INC, I guess)?
Yes. To give a random example from my system, App::Prove::State::Result::Test lives in a file named Test.pm in a (sub)directory called App/Prove/State/Result.
And, is that the only place where such a module could be found, or could it also be in a file of a different name and/or in a different subdirectory?
Yes, that's the only place where such a module could be found, though @INC may of course contain several places where Perl will look.
| [reply] |
|
|
|
|
And, is that the only place where such a module could be found, or could it also be in a file of a different name and/or in a different subdirectory?
Well, this is just a technicality that only applies to require, not use, but just for completeness:
You could take a module, for example Try::Tiny, copy its Tiny.pm to e.g. /tmp,
and include it via BEGIN { require "/tmp/Tiny.pm"; Try::Tiny->import() } and it'll work fine
- not that it's recommended :-)
If you only use use and modules from CPAN, then yes, the directory structure is pretty well defined (some rare, exotic modules may do things differently). The relevant documentation is use, require and @INC.
| [reply]
[d/l]
[select] |
Re: difference between packages and module
by displeaser (Hermit) on Jun 21, 2005 at 07:08 UTC
|
See also the perlmod doc that probably came with your perl distribution.
perldoc perlmod
Should bring it up for you locally.
It is also available on the Internet here: perlmod.
| [reply] |
Re: difference between packages and module
by davidrw (Prior) on Jun 21, 2005 at 12:43 UTC
|
The node Package vs. plain file may provide additional related information.
Also, Be sure to browse the "Writing, Installing, and Using Perl Modules" section of the Tutorials. These are two nodes from that section:
| [reply] |
Re: difference between packages and module
by tlm (Prior) on Jun 21, 2005 at 12:51 UTC
|
Here are a few small examples, roughly ordered from most to least typical.
| [reply]
[d/l]
[select] |
Re: difference between packages and module
by vinoth.ree (Monsignor) on Mar 12, 2009 at 05:10 UTC
|
* Packages are perl files with .pm extn and is considered a separate namespace. So a package is nothing but group of related scalars,arrays,hashes and subroutines for a
specific purpose.
Once a package is included in a .pl file
(using "use") and you want to call one of the subroutines
of the package, you may have to use the scope resolution
operator &package::subroutine1
* Modules are packages but which has the capabilities of
exporting selective subroutines/scalars/arrays/hashes of
the package to the namespace of the main package itself. So
for the interpreter these look as though the subroutines
are part of the main package itself and so there is no need
to use the scope resolution operator while calling them.
| [reply] |