Do you feel lucky?
Again correct, because the module does not *have* to even declare a
package.
It is free to load stuff into the calling packages namespace (main:: in
this
case), or even perform actions immediately. I have a silly package
which
syslog's '$0' and a timestamp to a central server, and sets up an END{}
to
syslog $0 and $? (return code) on its way out. It defined nothing of
use
to the caller. Any package which use's or require's this one will
immediately
log a 'script started at' and logs 'script finished at .. with rc=?'
when it
exits. Makes for easy audit trails.
BTW, a package Y in file X.pm is perfectly valid, though confusing. You
see you can have MANY packages in a single file.
All goes against good perl style of course. (or is that Perl style?)
>
> A blessed reference knows which *NAMESPACE* to find its methods in.
> If you have called 'use X;' *anywhere* in your code, or in a module
> or sub module, the namespace 'X' has been populated with the
> methods available.
>
Again this is the tricky part, the 'X' namespace hasn't been generated
by the 'use'... it has been generated by the 'package X' in the file
that 'use' loaded, which it is almost always acceptable to think of it
as the 'use' doing it, because 'package X' will normally be the first
thing in the file used, but technically not. Or do I have this wrong
too? You could 'use X' and have 'package Y' at the top of X.pm and not
end up with the 'X' namespace, but instead get a 'Y' namespace.
The question becomes do you want to...
http://danconia.org
[snip]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
