in reply to Problems with 'our' definition with perl 5.00503

Untested. 
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;

[download]
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.

Replies are listed 'Best First'.
Re^2: Problems with 'our' definition with perl 5.00503
by etcshadow (Priest) on Jun 30, 2005 at 05:23 UTC
    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)

    [download]
    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

    [download]
[reply]
[d/l]
[select]
      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;

      [download]
[reply]
[d/l]
        Wow... that's an escalation from funny to tragic. 
        me@host> perl -le 'print $]; print $^V; warn "No \"our\" declarations!
+\n" if $^V and $^V lt v5.6.0;'
5.00503

me@host>

        [download]
        ------------
:Wq
Not an editor command: Wq

        [download]
[reply]
[d/l]
[select]
      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.

      -- Foxcub
      #include www.liquidfusion.org.uk

[reply]

        I'm in a similar position, except with gcc instead of perl.

        The project I'm working on is written in C++, and is compiled with gcc 3.0. I once tried to compile everything with gcc 3.4. I've got loads of compilation errors, because newer versions of gcc try to approximate the C++ standard more closely, especially with templates. I started to correct them. I wanted to achive that those modules of the project that I need would compile cleany with both versions of gcc. (There are lots of other modules.) I've got permission to do any corrections, as long as they don't break with the older gcc, and they are clearly marked in the CVS log.

        I temporarily abandonned the whole proting thing when I realized that it's not only syntax issues that I'd have to change, but also the code depends on an internal class of the older version of libstdc++. The class is clearly marked internal and "may disappear in future versions", and its name starts with an underscore. I don't really understand what the class does, so I didn't dare touch it.

        Since then, gcc 4.0.0 came out.

[reply]
      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.
[reply]
        If you have a corresponding VARS placement, then you should definitely not be using our, and if you don't need it to be global then you should also not be using our. Just because the feature exists does not mean that it is appropriate. See Why is 'our' good? for some arguments that may convince you to solve your problem by using our less.
[reply]
      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.
[reply]

In Section Seekers of Perl Wisdom