global variables in a web service

Discussion in 'Perl Misc' started by sal.x.lopez@gmail.com, Jun 28, 2006.

  1. Guest

    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

    }
     
    , Jun 28, 2006
    #1
    1. Advertising

  2. Dodger Guest

    wrote:
    > 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'
     
    Dodger, Jun 29, 2006
    #2
    1. Advertising

  3. Tad McClellan, Jun 29, 2006
    #3
  4. Ben Morrow Guest

    Quoth "Dodger" <>:
    >
    > 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

    --
    Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
    From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
    (Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
    'Alcestis') [ flame, and falls out of sight. ]
     
    Ben Morrow, Jun 29, 2006
    #4
  5. wrote:
    > 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.
     
    Brian McCauley, Jun 29, 2006
    #5
  6. Dodger Guest

    Ben Morrow wrote:

    > 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, Jul 7, 2006
    #6
  7. Dodger Guest

    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.
     
    Dodger, Jul 7, 2006
    #7
  8. David Combs Guest

    In article <>,
    Brian McCauley <> wrote:
    >

    ....
    >
    >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
     
    David Combs, Jul 11, 2006
    #8
  9. David Combs <> wrote:

    > "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".


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jul 11, 2006
    #9
  10. Tad McClellan escribió:
    > David Combs <> wrote:
    >
    >> "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".
    >
    >

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

    hth
    --steph
     
    Stephan Titard, Jul 12, 2006
    #10
  11. Dr.Ruud Guest

    Stephan Titard schreef:
    > Tad McClellan:
    >> David Combs:


    >>> "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".

    >
    > 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

    --
    Affijn, Ruud

    "Gewoon is een tijger."
     
    Dr.Ruud, Jul 12, 2006
    #11
  12. -berlin.de Guest

    Dr.Ruud <> wrote in comp.lang.perl.misc:
    > 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
     
    -berlin.de, Jul 12, 2006
    #12
  13. Stephan Titard <> wrote:
    > Tad McClellan escribió:
    >> David Combs <> wrote:
    >>
    >>> "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".
    >>
    >>

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



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


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jul 12, 2006
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wayne
    Replies:
    2
    Views:
    476
    Wayne
    Nov 11, 2003
  2. jubelbrus
    Replies:
    5
    Views:
    619
    JohnQ
    Jul 20, 2007
  3. Leo Violette
    Replies:
    0
    Views:
    1,055
    Leo Violette
    Apr 17, 2009
  4. mark4asp
    Replies:
    1
    Views:
    221
  5. Tony Archer

    Global Variables? Multi-Application Variables?

    Tony Archer, Nov 24, 2003, in forum: ASP General
    Replies:
    5
    Views:
    225
    Tony Archer
    Nov 25, 2003
Loading...

Share This Page