On Wednesday, August 21, 2002, at 02:26 , [EMAIL PROTECTED] wrote:
[..]
p0: there is a virtue in
my $got_back = DTK::Flying::Wombat::flap(@funny);
since you know exactly what module you got that flap() from.
the alternative here is that you opt for what are known as
'utility classes' - where you use the 'method model' - but
do not carry around any specific 'data' in your 'object' hence
that would be in the form
my $wombat = new DTK::Flying::Wombat;
my $got_back = $wombat->flap(@funny);
and just skip the whole @EXPORT issue all together.
{ becoming my preferred strategy ... }
> 1: If I use exporter, what is the difference between
> @EXPORT and @EXPORT_OK.
> I have seen conflicting explanations.
> The perldoc does say to prefer EXPORT_OK.
p1: well as you start using
perldoc -m FOO::BAR
on some of the older modules you will find these
skanky little notes in them
'wish I had started with the EXPORT_OK....'
the problem with the @EXPORT is that it totally
pollutes the callers name space - which is sorta
ok-ish if your little module is never going to
grow any - Yeah Like as if that's gonna happen -
you got here because you have enough functions
that you need to re-use them....
So just start planning ahead for the need to
'micro-manage' the problem....
You will probably get into AUTOLOAD xor DYNALOAD
at some point - and decide that you only need to
load some of the functions when they are actually
called....
so I basically start by NOT using @EXPORT, and
start organizing the
our %EXPORT_TAGS = ( 'all' => [ qw(
) ] );
our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );
approach - and generally get into things like
our @EXPORT = ( );
our @EXPORT_OK = qw(
get_pids_for_pattern verbose_system do_pstack
getVersionOfPkg getFullPkgList
makeEid make_xml_file play_with_java ops_get_xml_response
);
our %EXPORT_TAGS = (
all => [ @EXPORT_OK ],
gen => [ qw(get_pids_for_pattern
verbose_system
do_pstack
)],
pkgfoo => [ qw(getVersionOfPkg
getFullPkgList) ],
xmlMsgFoo => [ qw( makeEid
make_xml_file
play_with_java
ops_get_xml_response
)],
);
hence one would call out
use FOO::BAR qw/:gen/;
or
use FOO::BAR qw/:xmlMsgFoo/;
or
use FOO::BAR qw/:gen :pkgfoo/;
or if all else fails
use FOO::BAR qw/:all/;
till you figure out which one's that script really needs
and decide to change the script to get only what you need
or change the perl module to provide a new ordering of
the functions.....
and only get those functions that you need...
> 2: IF I use either one (I have one function in my .pm, no
> OOP or bless).
> when I call use package,
> do I need to add qw(function) or not.
this is also tied up in the holy question
one or more perl module?
IF you opt to make small modules and it is intuitively
obvious that you will simply grow the use foo lines
use OurCool::FirstModule;
use OurCool::SecondModule;
use OurCool::FreakingThirdModule;
use OurCool::WhatDesignPatternModule;
....
use OurCool::KILLmanagementTheyAreDrivingMeInsaneModule;
then stuffing everything into the @EXPORT and not using
the 'qw/<tagFoo>/'; { yes, I know that the perldoc -f use
refers to that as a LIST.... } will suffice....
granted, as noted, you can avoid all of that with the
OO model - and hope that your design pattern by definition
was as clean as it was suppose to be - so that when you
are some three or four subclasses into the mess that you
are not needing massive convolutions to reach through
the inheritence hierarchy for the SUPER::SUPER::DUPER....
If all works out right you are long gone before anyone
notices that there is an under-featurefulness in any
of the strategies you tried....
> 3: And does that depend on using EXPORT or EXPORT_OK.
yes....
8-)
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
