Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

All,

Inherited a venerable project some time ago, full of amazing wonder and delight which dates back to the ancient time of perl 4.036. It's been well cared for over the years, and despite many perl version upgrades has performed successfully in every way, only needing minor tweaks and such to keep it 100% functional. A marvel.

These days, the code has now met its match in terms of syntax, and I guess the looser assumptions of how modules get require'd and how calls get made no longer hold true. An example in really short terms, given a script and its package, main.pl and package.pl. 

main.pl:

#/usr/bin/perl

print "Entry point\n";
log('started');

sub log {
# do the usual to open the logile

# now print it
print LOG @_;

# close it
}

[download]

And now the package: 

package.pl:

package mutex;

sub update {
# do something and log it
&main'log("can't do something");
}

1;

[download]

I'm waaay oversimplifying many lines of code, but you get the idea.

So, in the old days, this would work: The package could call a routine in the calling routine and continue. It seems this worked fine until around perl 5.26 and now we get the "Undefined subroutine &main::log called at". Has the way this once worked before changed? Before anyone asks: There's a lot going on in the log() routine that would make it very hard to locate into its own package, and even then, I'm not sure package calling package will work.

Thanks,

Replies are listed 'Best First'.
Re: Perl's changes in the use of packages
by Marshall (Canon) on Jul 07, 2017 at 00:05 UTC
    The main package doesn't call anything in package mutex. There of course are issues in that package mutex is contained with the file package.pl and there is nothing to say how main:: would even find the sub "update" which is contained in the package mutex which itself is contained within the file package.pl

    I think some more work is in order in order to get a submission that actually runs. I don't see how even with Perl 4 that this code would work or that the the existence or not of file: package.pl would even matter at all.

    Update:
    I started working with Perl in the 1990's with Perl 5.6. As Perl has evolved, I've seen some of my old code at least produce warnings with new versions of Perl that it didn't before and I've had to modify that code. Perl 4 is very old. It could be time to just re-write it?

[reply]
Re: Perl's changes in the use of packages
by Anonymous Monk on Jul 06, 2017 at 19:45 UTC
    You've simplified too much, that code works on 5.26, give us something we can run that shows the error
[reply]

      Don't the usual conventions apply for all symbols.

      If you can't resolve it, it doesn't exist (at least with use strict or no AUTOLOADING)... meaning that either log would be an entry in %main:: or else it needs to be explicitly called by its package name.

      I don't see the mystery...

[reply]
Re: Perl's changes in the use of packages
by Anonymous Monk on Jul 07, 2017 at 02:17 UTC
    Suspect that you aren't meant to run package.pl on its own, but main.pl is supposed to
    do 'package.pl';

    Back in the day, .pl stood for "perl library", and that's how you loaded your libraries. Nowdays, the preferred extension for loadable modules is .pm ("perl module"), and many people use .pl to stand for "perl script" (though on unix-y systems, scripts often have no extension).

[reply]
Re: Perl's changes in the use of packages
by 1nickt (Canon) on Jul 06, 2017 at 18:48 UTC

    What is the benefit you are deriving from constantly upgrading your Perl version?


    The way forward always starts with a minimal test.
[reply]
      I'm not sure what's the OP's benefit, but I've witnessed the drawbacks of not doing so:
      • You can't use modules from CPAN, at best you need to search backpan for old versions (in my case, our client switched from FTP to SFTP);
      • You can't switch to a new OS version or architecture smoothly (see The Unicode Bug with Transliteration or Substitution for an example);
      • Old security bugs lurking (hash randomization etc.). 
      ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,

      [download]
[reply]
[d/l]

        All valid points. I am of course not suggesting to never update your Perl version. But I would think that for the OP, given how he described his code, keeping up with the very latest Perl might be unnecessarily far in the other direction.


        The way forward always starts with a minimal test.
[reply]
      Some have already said what the benefits are, but in our case, it's driven by those sysadmin who rule by fiat and must always upgrade to the latest version of this or that OS. So, we must roll with it.
[reply]
Re: Perl's changes in the use of packages
by Anonymous Monk on Jul 07, 2017 at 19:51 UTC
    Bah, I knew this was too good to be true.

    To clarify, yes, main.pl would also do "require mutex.pl"; somewhere in the program.

    Unfortunately I can't post the actual code as it is several thousand lines long of perl that dynamically creates web pages as one of its tasks. When run under mod_perl (offered to us, so why not try it?), that when we were told the code had problems.

[reply]

Back to Seekers of Perl Wisdom