in reply to $^W or require warnings and import warnings;

If I understand this correctly the author thinks it is important to turn on warnings for the script but not necessary for modules it uses. Hence at least for perl >= 5.6 they go for the lexically scoped warnings.

I tend to look at this as the author saying: I must have warnings on in my code, I'll try not to turn it on in the modules I use so they don't break in strange ways, but in perl's before 5.6 I have no choice.

I guess they're trying to make their code as compatible as possible with perl's before 5.6 and strangely written modules, but it does seem rather cargo-cultish. On a side note: perl 5.6 has been out a long time, so I don't really see the point. Why would someone run something new like Subversion, and not bother to upgrade their ancient Perl? Upgrading parts of your system while other parts are left to rot in legacy mode just seems like trouble.

  • Comment on Re: $^W or require warnings and import warnings;

Replies are listed 'Best First'.
Re^2: $^W or require warnings and import warnings;
by Transient (Hermit) on Jun 15, 2005 at 17:46 UTC
    I guess they're trying to make their code as compatible as possible with perl's before 5.6 and strangely written modules, but it does seem rather cargo-cultish. On a side note: perl 5.6 has been out a long time, so I don't really see the point. Why would someone run something new like Subversion, and not bother to upgrade their ancient Perl? Upgrading parts of your system while other parts are left to rot in legacy mode just seems like trouble.


    I think it might be jumping the gun to call that "cargo cult". There are probably lots of corporations out there who don't make upgrading perl a priority. I don't see why (if you had the time) you wouldn't include such a line.
[reply]
      The problem I have with blindly including something like this is that if you expect a script to work on an ancient version of perl you need to go through hoops to avoid using newer constructs/modules, and more importantly, you really should test your script on those old versions. It's nice to be compatible, but if your script breaks on an ancient version of perl that you "support" you are not doing the poor user any favors. It's actually nicer in the long run to just say "we require 5.6 or newer" and let them install a separate copy of perl if they need to.

      Please note that I'm not saying they are doing this in this particular case, perhaps they have actually tested this on older perls. It just that it seems that way to me at first glance from the posted snippet (which may be assuming too much)...

[reply]
        That I definitely agree with. If there is any portion of the module that does not support pre-5.6, then it is much better to simply require 5.6 instead.
[reply]
Re^2: $^W or require warnings and import warnings;
by duff (Parson) on Jun 15, 2005 at 17:49 UTC
    Why would someone run something new like Subversion, and not bother to upgrade their ancient Perl? Upgrading parts of your system while other parts are left to rot in legacy mode just seems like trouble.

    Thus spake someone who hasn't had to maintain systems for the long term. :-)

    Many times it is necessary that particular versions of perl, modules, libraries, etc. are all required just to make the mission-critical application work. "Upgrading" is often counter productive and costly (due to time lost chasing down weird interactions and fixing them among other things).

    Switching from CVS to SVN (for instance) is something that is likely to only affect the development team while switching from perl 5.005_04 to 5.8.6 may affect everybody.

    duff

[reply]
      I understand about having to keep a legacy perl around to support older apps, etc, and I don't have a problem with that. It just seems like a no-brainer to also have an additional up-to-date perl (i.e. a separate install) if you plan on using up-to-date scripts. Chances are very good that these new scripts weren't actually designed or tested on your legacy perl (i.e. you'll need to test/examine them). Having a separate perl seems a lot easier to me than examining every new script you put on the machine to make sure it's going to work with your legacy perl.
[reply]
        Having a separate perl seems a lot easier to me than examining every new script you put on the machine to make sure it's going to work with your legacy perl.

        Sure ... if you're even allowed to install a new perl on the machine. Often political or social concerns override the obvious technical solutions. Especially when "legacy systems" are concerned.

        duff

[reply]

In Section Seekers of Perl Wisdom