Re^2: Problems with 'our' definition with perl 5.00503

Replies are listed 'Best First'.
Re^3: Problems with 'our' definition with perl 5.00503 by tilly (Archbishop) on Jun 30, 2005 at 17:02 UTC
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]
Re^4: Problems with 'our' definition with perl 5.00503 by etcshadow (Priest) on Jun 30, 2005 at 18:50 UTC
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]
Re^3: Problems with 'our' definition with perl 5.00503 by Tanalis (Curate) on Jun 30, 2005 at 15:14 UTC
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]
Re^4: Problems with 'our' definition with perl 5.00503 by ambrus (Abbot) on Jun 30, 2005 at 16:19 UTC
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]
Re^3: Problems with 'our' definition with perl 5.00503 by cosmicperl (Chaplain) on Jun 30, 2005 at 14:37 UTC
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]
Re^4: Problems with 'our' definition with perl 5.00503 by tilly (Archbishop) on Jun 30, 2005 at 17:06 UTC
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]
Re^3: Problems with 'our' definition with perl 5.00503 by cosmicperl (Chaplain) on Jun 30, 2005 at 16:25 UTC
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]