On 08/02/2012 09:51 AM, Mark Haney wrote:
On 08/02/2012 09:57 AM, Shlomi Fish wrote:
Hi Mark,
So, should I use it? Does it really matter in small apps? What am I
missing here?
Can you give a code sample that reproduces the issue?
Let me see if I can explain better. I have a Package called EMBMON::DAO
which (as may be obvious) handles the object for accessing the database.
This one does NOT have an EXPORT line yet nearly all the code in the web
app uses the subroutines (about 2 dozen) in this package.
So - there are subroutines that are being called in the package as
subroutine calls e.g.
my $answer = dosomething($some,@parameter);
(As opposed to some methods being called in the class like
my $dao_thing = EMBMON::DAO->new(%configuration);
$dao_thing->do_something($some,@parameter);
To do the first, your package would have to perform the same "magic"
that Exporter would do - which would work the same. I'd recommend using
Exporter because it provides a rich feature set that is known to work
and is well documented.
I also have a package EMBMON::UTIL that houses various subroutines for
things like calculating averages or other things specific to the app.
There are only 6 subs in that package and it HAS an EXPORT line
exporting the subs in the package.
Which is probably the better thing to do.
As I age, I find myself importing names into my package namespace less
and less often - I actually prefer to use the fully qualified subroutine
names, because it makes it (in my opinion) easier to find the
documentation for a specific function call.
Of course, being a big old OO bigot - I prefer objects and their method
calls to functions any day of the week and twice on Sundays.
--L
Vaguely, I knew there was a difference in modules and packages, but
nothing I've ever had to write has really required modules and only one
or two packages.
Does this help?
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
