best practice ... requires

M

mike

i'm having trouble with variables

I have a main cgi script ... lets call it main.cgi

In main.cgi i have some other perl scripts that have subroutines

#!/usr/bin/perl -w
#
# name of this program is: main.cgi
#

use CGI;
use Cwd; #used to get the current working directory
$filebase = cwd;

#requires here
require "$filebase/some.lib";
require "$filebase/a.pl";
require "$filebase/b.pl";
require "$filebase/c.pl";

my $x = &do this;

So the question is:
1) if i dont use a subroutine that is in some.lib here in main.cgi but
in a.pl is it better to remove the require from main.cgi and put it in
a.pl?
2) can my require in main.cgi be global since the vars in some.lib are
used in a.pl, b.pl, and c.pl?

thanks 4 any help.

Mike
 
G

Gunnar Hjalmarsson

mike said:
i'm having trouble with variables

What kind of trouble??
I have a main cgi script ... lets call it main.cgi

In main.cgi i have some other perl scripts that have subroutines

#!/usr/bin/perl -w
#
# name of this program is: main.cgi
#

use CGI;
use Cwd; #used to get the current working directory
$filebase = cwd;

#requires here
require "$filebase/some.lib";
require "$filebase/a.pl";
require "$filebase/b.pl";
require "$filebase/c.pl";

my $x = &do this;

So the question is:
1) if i dont use a subroutine that is in some.lib here in main.cgi but
in a.pl is it better to remove the require from main.cgi and put it in
a.pl?

If you also import symbols from some.lib and the subroutines are in a
separate package, it's better to require the library from the script
that is using the subs. Otherwise it doesn't matter.
2) can my require in main.cgi be global since the vars in some.lib are
used in a.pl, b.pl, and c.pl?

What does "global" mean here?
 
X

xhoster

mike said:
i'm having trouble with variables

I have a main cgi script ... lets call it main.cgi

In main.cgi i have some other perl scripts that have subroutines

#!/usr/bin/perl -w
#
# name of this program is: main.cgi
#

You should use strict;
use CGI;
use Cwd; #used to get the current working directory
$filebase = cwd;

#requires here
require "$filebase/some.lib";
require "$filebase/a.pl";
require "$filebase/b.pl";
require "$filebase/c.pl";

I think use is usually better than require for this type of stuff.
And if "." is in your @INC, then it will automatically search cwd for them.

my $x = &do this;

Why are using this syntax?
So the question is:
1) if i dont use a subroutine that is in some.lib here in main.cgi but
in a.pl is it better to remove the require from main.cgi and put it in
a.pl?

Probably, yes.
2) can my require in main.cgi be global since the vars in some.lib are
used in a.pl, b.pl, and c.pl?

Does your library or any of the scripts change the package?

"package" variables in some.lib can be used from anywhere, they just need
to be fully qualified with a package name if you are using them from
another package (or even from the same package under strict.)

Xho
 
C

comp.llang.perl.moderated

i'm having trouble with variables

I have a main cgi script ... lets call it main.cgi

In main.cgi i have some other perl scripts that have subroutines

#!/usr/bin/perl -w
#
# name of this program is: main.cgi
#

use CGI;
use Cwd; #used to get the current working directory
$filebase = cwd;

#requires here
require "$filebase/some.lib";
require "$filebase/a.pl";
require "$filebase/b.pl";
require "$filebase/c.pl";

my $x = &do this;

So the question is:
1) if i dont use a subroutine that is in some.lib here in main.cgi but
in a.pl is it better to remove the require from main.cgi and put it in
a.pl?

Yes, clearer IMO to put the require in a.pl since
the subroutine's used there and not in main.cgi.
2) can my require in main.cgi be global since the vars in some.lib are
used in a.pl, b.pl, and c.pl?

Yes, as already noted, package variables defined
earlier in some.lib can be used later downstream if fully qualified.
This applies to subroutines as well.
The package qualifier can be omitted only if
the definitions are in package 'main'. But,
polluting main from files pulled in via require
isn't a good idea.
 
M

mike

Ok, so i decided to use packages.

my scripts would look something like:

#!/usr/bin/perl -w
#
# name of this program is: main.cgi
#
use CGI;
use pkg_a;
use pkg_b;
my $x = &pkg_a::do_this();

#!/usr/bin/perl -w
#
# name of this program is: pkg_a.pm
#
package pkg_a;

sub do_this()
{
&pkg_b::do_that();
}

so you can see that my package is nested and I am now wondering how
correctly to do this. You can see that I am calling a package from
inside a package. I dont know if that is legal or not.

I am getting this error message: Illegal character in prototype

I dont know if it because the packages are nested or if i have some
other problem.

Thanks
 
G

Gunnar Hjalmarsson

mike said:
Ok, so i decided to use packages.

my scripts would look something like:

#!/usr/bin/perl -w
#
# name of this program is: main.cgi
#
use CGI;
use pkg_a;
use pkg_b;
my $x = &pkg_a::do_this();

#!/usr/bin/perl -w
#
# name of this program is: pkg_a.pm
#
package pkg_a;

sub do_this()
-------------^^
Skip those parentheses (i.e. don't bother with prototypes)
{
&pkg_b::do_that();
}

so you can see that my package is nested and I am now wondering how
correctly to do this. You can see that I am calling a package from
inside a package. I dont know if that is legal or not.

You have already been told that it works.
I am getting this error message: Illegal character in prototype

See above.
 
B

Ben Morrow

Quoth mike said:
Ok, so i decided to use packages.

my scripts would look something like:

#!/usr/bin/perl -w

Don't use -w, use

use warnings;

You need

use strict;

here as well. Have you seen the posting guidelines?
#
# name of this program is: main.cgi
#
use CGI;
use pkg_a;

Packages with all lowercase names are reserved for pragmas (modules that
affect the way Perl parses your program, like strict and warnings).
Also, you should give your modules descriptive names (although I presume
this is just an example).

use PkgA;
use pkg_b;
my $x = &pkg_a::do_this();

Do you know what calling a sub with & does? I thought not. So don't do
it. You can avoid needing to call subs by their fully-qualified name by
using Exporter: see perldoc Exporter.
#!/usr/bin/perl -w
#
# name of this program is: pkg_a.pm
#
package pkg_a;

You need

use strict;
use warnings;

here as well. They only apply to the file in which they appear. (Yes,
this is annoying :).)
sub do_this()

Don't use prototypes unless you know what they do: Perl is not
Javascript.

sub do_this {

(Also, as a style issue, it is usual in Perl code to put the { on the
end of the line... it's not terribly important, but it can confuse
people.)
{
&pkg_b::do_that();
}

so you can see that my package is nested and I am now wondering how
correctly to do this. You can see that I am calling a package from
inside a package. I dont know if that is legal or not.

Your packages are not 'nested'. You simply have three packages:

main, defined in main.cgi;
pkg_a, defined in pkg_a.pm;
pkg_b, defined in pkg_b.pm.

Calling a function in pkg_b from pkg_a is no different from calling a
function in pkg_a from main. In order to keep pkg_a self-contained, you
should have a

use pkg_b;

at the top of pkg_a.pm as well: Perl will not load it more than once.
Then, when you've learned to use Exporter, you can import some subs into
pkg_a and some into main, and everything will be much neater :).
I am getting this error message: Illegal character in prototype

No, you're not; well, not from that code, anyway. The 'prototype' is
this bit:

sub do_this()
^^

which isn't anything like the formal argument list other languages might
have here. I suspect your real code has something like

sub do_this($param)

which is not valid Perl. Simply omit the parens until you understand how
prototypes work in Perl.

Ben
 
M

mike

So if I have some parameters to pass to the subroutine how do I do
that without a prototype?

Mike
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,813
Latest member
lawrwtwinkle111

Latest Threads

Top