global variables in a web service

[sal.x.lopez]

How do I set global variables in a web service script so that they are
available to all functions? In my code below, and when called by the
client, the variable $str is empty within the helloWorld subroutine.

#!/bin/perl

use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
->dispatch_to('DEMO')
->handle;

package DEMO;

my $str = "Hello World";

sub helloWorld {

my ($arg1, $arg2) = @_;

print "$str\n";

# do other stuff

}

 

[Dodger]

How do I set global variables in a web service script so that they are
available to all functions? In my code below, and when called by the
client, the variable $str is empty within the helloWorld subroutine.

#!/bin/perl

use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
->dispatch_to('DEMO')
->handle;

package DEMO;

my $str = "Hello World";

sub helloWorld {

my ($arg1, $arg2) = @_;

print "$str\n";

# do other stuff

}

For that case, use our() not my(), or predeclare the variable.

our() creates a package global.
This is not necessarily a true global, especially in a webserver
environment. That's probably what you want. I know you asked for a true
global, but I have some doubt as to whether you really want a true
global -- such would be shared with other requests and things and could
be bad: consider:

User 'schmoo' logs in and has the $handle variable set. You've made
this a true global.
Another user comes in and doesn't log in. The script is set to say
'Welcome, Guest' if the $handle variable isn't set or 'Welcome $handle'
if it is. You'd expect the second user to see 'Welcome Guest' but if
nothing specifically unsets $handle from being 'Schmoo' and $handle is
a true global, the unlogged in user will see 'Welcome Schmoo' instead.
This could be bad if, for instance, you have private information,
administrative functions, or consumer downloadables, for instance.

Secondly, such true globals will only be true to the server process
that they start in. Sone most webservers have anywhere form 5 to 500
child processes running to handle the traffic at one time, those would
be all entirely seperate processes.

So yeah, it's probably a package global you want, and therefore
our $variable = 'FooBar'

 

[Tad McClellan]

How do I set global variables

"Coping with Scoping":

http://perl.plover.com/FAQs/Namespaces.html

 

[Ben Morrow]

For that case, use our() not my(), or predeclare the variable.

our() creates a package global.
This is not necessarily a true global, especially in a webserver
environment.

Please explain what you think a 'true' global is if a package variable
isn't one.

Ben

 

[Brian McCauley]

How do I set global variables in a web service script so that they are
available to all functions? In my code below, and when called by the
client, the variable $str is empty within the helloWorld subroutine.

#!/bin/perl

use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
->dispatch_to('DEMO')
->handle;

package DEMO;

my $str = "Hello World";

sub helloWorld {

my ($arg1, $arg2) = @_;

print "$str\n";

# do other stuff

}

You should always enable warnings.

I'm guessing you are running this under mod_perl. If so you should see
your logs full of ..

Variable "..." will not stay shared

This is because Perl doesn't properly implement nested subroutines in
the was that, say, Pascal does and mod_perl wraps you script in "sub
handler {...}".

For details look up the above warning message in perldiag.

My perfered solution is to use package variables and dynamic scoping.

Yes I realise that there are issues with package variables and dynamic
scoping but this really is one of those cases where the disadvantages
are minimal. Would still advise all to understand the semantics of
package variables before usign them. See the local() and our()
functions.

I perfer to say "package variables" not "global variables" because as
the OP correctly implied the file-scoped lexical is also a global
variable of sorts from the design point of view.

When using CGI scripts under mod_perl simply replace "my" by "local
our" for those variables declared in the outermost scope which trigger
the will not stay shared
warning.

Note this is still a somewhat dirty hack. Consider instead moving DEMO
into a separate ,pm file or writing a real mod_perl handler rather than
using one of the CGI emmulation modes.

 

[Dodger]

Please explain what you think a 'true' global is if a package variable
isn't one.

While I was honestly tempted to just say 'no' and to qualify that by
stating that I don't *think* I *know*...

http://perldoc.perl.org/perlvar.html

They're in there.

 

[Dodger]

Though admittedly, I was more referring to the fact that registry
scripts under mod_perl are evaled and thus sort of run in a sandbox of
sorts, where to reach things in Main:: you have to do so explicitly --
and usually you don't really want to.

 

[David Combs]

....

My perfered solution is to use package variables and dynamic scoping.

"Dynamic scoping" -- nice terminology.

Why? Because (I assume) lots of computer-sci books on
general language implementation (and explanation) use it;
it is (or was) something pretty much everyone who in
cs courses studied languages like lisp and its relatives
and children.

Larry, of course, has chosen the seemingly opposite-meaning
term "local" for the concept in perl.

Sure would be nice if for p6 he'd switch to the more-generally
(across cs) terminology: people coming to perl from other
(interpretive) languages would know instantly what
it meant.

Unfortunately, those same people, seeing "local",
*also* think they understand *that*!


David

 

[Tad McClellan]

"Dynamic scoping" -- nice terminology.

Larry, of course, has chosen the seemingly opposite-meaning
term "local" for the concept in perl.

The biggest cause of the local() confusion is that "local" is short
for something, and most folks fillin the wrong something.

local() makes a "local value", not a "local variable".

 

[Stephan Titard]

Tad McClellan escribió:

The biggest cause of the local() confusion is that "local" is short
for something, and most folks fillin the wrong something.

local() makes a "local value", not a "local variable".

yes. Around here I tell people it is short for "localize"

hth
--steph

 

[Dr.Ruud]

Stephan Titard schreef:

Tad McClellan:

yes. Around here I tell people it is short for "localize"

In Perl6 it is renamed to "temp" (and also see "let").
http://dev.perl.org/perl6/doc/design/syn/S04.html

 

[anno4000]

Stephan Titard schreef:
[local()]

In Perl6 it is renamed to "temp" (and also see "let").

A very good choice. Dynamic binding is best described in temporal
terms: the value is valid *until* control leaves the block. Lexical
scope is described in spatial terms: the variable is only accessible
*inside* the block. In that view, "my" ought to be called "local",
but even Perl6 won't go that far.

Anno

 

[Tad McClellan]

Tad McClellan escribió:
yes. Around here I tell people it is short for "localize"

I tell them it is short for "save and restore".