Re^3: alternative way to subs

A package declaration just says "Unless I specifically say otherwise by qualifying them, any symbol table references (subroutine definitions, global (package) variable references via our, etc) I make should be understood to be going into this package until I say otherwise or the current scope ends". There's no written-in-stone correspondence between any given package and only one file. If you really wanted to you could have n different files all putting things into the same one package, or one file which puts subs in m different packages. Convention and normal usage tends to be one-package-per-file, but that's again convention not a requirement.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re^3: alternative way to subs

Replies are listed 'Best First'.
Re^4: alternative way to subs by Zen (Deacon) on Apr 30, 2008 at 15:54 UTC
Thanks for clarifying. I generally see this done all in one .pm, which is why I asked. I'm not sure what his strategy is by separating out the exporter lines from the package. I've always seen it done by putting that in the same .pm as the package. This is a design question, not a question of the perl validity.	[reply]
Re^5: alternative way to subs by shmem (Chancellor) on Apr 30, 2008 at 16:57 UTC
The goal here is to only load the .pm file, pre-declare the functions or methods in it without actually compiling them. They are loaded on demand via AutoLoader's AUTOLOAD subroutine. If the functions/methods were in the same .pm file, they would all be compiled at the time of use. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]