Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Problems with 'our' definition with perl 5.00503

by cosmicperl (Chaplain)
on Jun 30, 2005 at 00:24 UTC ( #471192=perlquestion: print w/replies, xml ) Need Help??
cosmicperl has asked for the wisdom of the Perl Monks concerning the following question:

Hi Guys,
   I've hit a problem installing one of my scripts on a server. The guy is running perl version 5.00503. It's having problems with each time I've used the "our" declaration for variables.

I update my code often so changing every occurance of our to my manually or using a script isn't favorable and I'd have to do it each time I update them (and I'm bound to forget).

I'm going to try to get his host to upgrade to perl version 5.8 or 5.6. But if they don't what I would like to be able to do is add a piece of code to the top of each script which:-
1. Checks in the our definition is avaiable.
2. If it isn't creates an our definition that sits on my so in effect acts as my.

Please help

  • Comment on Problems with 'our' definition with perl 5.00503

Replies are listed 'Best First'.
Re: Problems with 'our' definition with perl 5.00503
by BrowserUk (Pope) on Jun 30, 2005 at 01:03 UTC

    If your uses of our can be substituted with my, why are you using our?

    They are not interchangable. If you can use my wherever you are currently using our you should do so.

    Otherwise, if your code has to run on 5.005, you could use vars q/ $x $y $z/; and that will run both pre- and post-5.6.

    But really, you should only use our when you cannot use my.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
Re: Problems with 'our' definition with perl 5.00503
by tilly (Archbishop) on Jun 30, 2005 at 04:07 UTC
    package strictitude; require strict; *unimport = \&strict::unimport; sub import { if ($^V and $^V lt v5.6.0) { my $pkg = caller; *{"$pkg\::our"} = sub {@_[0..$#_]}; } else { goto &strict::import; } } 1;
    and then use strictitude rather than strict.

    The idea is simple, if the Perl version is too low, export a useless our function to prevent errors and turn off strict checks. For recent Perls do what strict does so you can catch undeclared variables.

      I mean absolutely no derision as I point this out, but I do find humor in the situation: You're using features which were introduced later than 5.005_03 to detect whether or not the interpretter is later than 5.005_03. Neither $^V nor v-strings exist in 5.005_03.

      You probably want your conditional to be:

      if ($] and $] < 5.006)
      It works under 5.5 and under 5.6/5.8 as well. I know I've got to be one of the few monks around here that still lives in 5.005_03.
      ------------ :Wq Not an editor command: Wq
        You should send in a documentation patch for perlvar then, because I pulled this line from there:
        This can be used to determine whether the Perl interpreter exe- cuting a script is in the right range of versions. (Mnemonic: use ^V for Version Control.) Example: warn "No \"our\" declarations!\n" if $^V and $^V lt v5.6.0;
        I can sympathise completely - the shop I work for is still down there in Perl 5.005 .. with "no plans to upgrade in the forseeable future" in case it breaks things.
        Ok, almost there
        The project is a constant work in progress, most of the our definitions could be changed to my, but will need our in the future. All 'our's that need to be global right now have a corrosponding VARS placement so that shouldn't cause any problem.

        I'm not using strict at this stage in this particular script. That code looks almost like what I need, but without referencing my on any our calls.
        The main errors I'm getting is something like this:-
        "our %hash;" - error illegal modulas of 0. Because our isn't defined it's treating % as a modulas.

        I'm sure the solution is quite simple, I just don't quite know how to do it.
        The host has got back to me saying the server is part of a nest and they don't want to upgrade all of them, but I'm still trying.

        Thanks in advance.
        I'm sure something like this is possible:-
        *{"&our"} = \&{my};
        I know it's wrong and doesn't work. But I'm sure one of you wise monks know how to do it.
Re: Problems with 'our' definition with perl 5.00503
by Tanktalus (Canon) on Jun 30, 2005 at 00:48 UTC

    While it sounds like you want some sort of Filter::Simple that does this conversion, that's just a bad idea to me. Better to have a Makefile.PL or Build.PL which calls a conversion script that converts during "make" or "Build" and then installs.

    But I'd stick to my guns on the perl 5.8 upgrade - 5.005 is really old and not as well supported.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://471192]
Approved by GrandFather
Front-paged by Courage
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2017-02-24 20:09 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (363 votes). Check out past polls.