On Sunday, July 14, 2002, at 07:21 , chris wrote:
> Sounds like I am unable to reference the sub unless I make the
> necessary changes in the package.
yes and no....
first the 'no side' - since you may need to 'get the code up
and running now' = you can Work Around the problem by fully
qualifying the path to the function - as it were....
I have used the trick of
use DTK::WebAccess;
...
DTK::WebAccess::dtk_openSocket_to_webPage( $host, $port, $fd);
and
use DTK::WebAccess qw/dtk_openSocket_to_webPage/;
...
dtk_openSocket_to_webPage( $host, $port, $fd);
in places - depending upon whether I am more or less angst
ridden about remembering WHERE a 'function' came from....
My persona rule of thumb for 'modules' is that IF I need to
'reference' a private 'function' { one I am not going to export }
or one I have exported - inside some other function - I do
the first style....
package FOO::BAR;
..
sub do_cool {
my ($foo,$bar,$baz) = @_;
...
return($cool_reality);
}
....
sub reality_check {
my ($input1, $input2) = @_;
....
my $state = FOO::BAR::do_cool($a, $b, $c);
...
}
...
This way i know that IF the user calls MY reality_check,
that I don't have to worry about which 'do_cool()' function
we are playing with.... { hence, IF I opt to restructure
later on - I know which one I meant to use as well... }
at times - simply to access a Single Function out of a module
without needing to Import Everything or anything specific
form the Module....
Think of it as
use FOO::BAR;
as, well the compile time directive of
{ require FOO::BAR ; import FOO::BAR }
and if nothing is expressly 'exported' into your name space
then You have to 'fully qualify' what you want to use in
that 'name space':
FOO::BAR::some_func(@some_args);
remember that a 'sub' in your script is a 'name space' element.
We tend to use the short hand of
my $got_back = some_func(@some_args);
since perl will look first for it as
my $got_back = main::some_func(@some_args);
since it IS a part of the 'main' name space....
just as:
my $main::got_back = main::some_func(@some_args);
if we were going to be - 'fully qualified'....
So one can IMPROVISE around the fact that your
'module' was 'built' some 'other way'.... that is
now causing you problems.
on the 'yes side' - making the changes will help you
better sort out which functions should be grouped together
and referenced in 'groups' by their 'tags'....
Think of this as the
WOW! I now have them all in one file!
How exactly do I want to 'export them back to scripts'?
type of problem....
> The use of %EXPORT_TAGS and
> @EXPORT_OK are considerations in the package's design. Am I
> understanding this correctly?
yes....
see specifically -
perldoc Exporter
do the preliminary reading in:
perlsub Perl subroutines
perlmod Perl modules: how they work
perlmodlib Perl modules: how to write and use
perlmodinstall Perl modules: how to install from CPAN
cf: perldoc h2xs - and you will find that it lays out a
really nice base line for your basic perl module.... including
some useful advice about
a) don't just export everything
b) some tricks on how to use export
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
