The "cat" sub is declared in the "my_mod" namespace, and it is NOT in your "dog" script.

The reference needs to be explicit, unless you Export/import the names (a more advanced topic than you probably care for at the moment).

Try calling like this from 'dog":

  my_mod::cat();
[download]

  my $kitten = new my_mod;

  $kitten->cat(); # No need to qualify - $kitten already has access to
+ the my_mod namespace.
[download]

Used  my_mod::cat();. It worked.

package my_mod;

BEGIN {
   our @ISA = 'Exporter';
   our @EXPORT_OK = qw( cat );
   require Exporter;
}

sub cat{
  print "meeow.\n";
}

1;
[download]

use my_mod qw( cat );
cat();
[download]

You can also do use my_mod qw(cat) ... in other words, declaring the names from my_mod that you wish to, well, “import from” it.

Two ways ... export or import ... same cat.   (meow...)

And actually, I find that the explicit use of name-space references (e.g. my_mod::cat) can actually be quite useful, since it explicitly declares where the names are expected to come from. Anyone who's looking at the code can tell at a glance, not only “where to look,” but also “the one-and-only place where the computer will be looking.”   (purrr....)

Consider: when you use a library that exports a whole lot of things, it could be argued that you run the risk of “polluting your namespace” with a bunch of exported routines that you don't need... and that you were not explicitly aware of. This can be the source of much grief, with the commensurate abuse of available hair-follicles.

Certainly one of the most annoying and time-wasting (hence, expensive!) sources of bugs are those where you thought you knew how the computer was interpreting a particular line of source-code, but you actually didn't. That's one reason why I rather prefer the “imports” approach rather than “exports.” It allows you to understand the behavior and the proper reading of a particular package fully when looking only at that package. To me, that's a very desirable characteristic for source-code to have.

I don't make such an observation “dogmatically,” of course. Very few things in this business are truly dogmatic. But I do observe it to be characteristically useful.

You can also do use my_mod qw(cat) ... in other words, declaring the names from my_mod that you wish to, well, “import from” it.

I personally believe you missed something very important: what you suggest will only work if my_mod uses Exporter (or otherwise reimplements its functionality, to be really anal) to include cat in the list of symbols allowed to be exported, through @EXPORT_OK.

Simply doing what you suggest will only cause the use statement to call my_mod->import('cat'). But the import method must be implemented, and Exporter provides a "standard", flexible way to do so.

PS: why are you using <tt> tags? Code tags should be the preferred way to refer to code, be it a single name, in PM. And <c> is even easier to type, than <tt>.

--
If you can't understand the incipit, then please check the IPB Campaign.

sub daddy{ print "Hi, Dad!!!\n"};
[download]

my_mod::daddy();
[download]

I think we need to see the new code in situ -- as described, it sounds like it should work.
--
Wade

my_mod.pm:

package my_mod;

sub cat{
  print "meeow.\n";
}

sub daddy{ print "Hi, Dad!!!\n";}

1;
[download]

Here is dog:

 
#!/usr/bin/env perl

use my_mod;

my_mod::cat();
my_mod::daddy();
[download]

I tried this exact same on a separate box with a (presumably) different Perl interpreter, and it seemed to work just fine. Could it be something weird going on with the cygwin perl interpreter? And speaking of which, is there any way I could obtain Perl (at least an interpeter, compiler) for Windows (without having to use ActiveState Perl, for which I must eventually pay money)? The Perl interpreter that comes with cygwin is, to say the least, a little squirrelly (okay, maybe my code is too, but still...).