Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

future warnings

by ysth (Canon)
on Jul 08, 2004 at 23:48 UTC ( #373005=perlmeditation: print w/ replies, xml ) Need Help??

There've been a number of times when valuable new warnings are introduced in perl development versions, but can't be put in a maintenance version because people rightly expect previously warnings-free code to stay that way when upgrading from, say, 5.8.1 to 5.8.3. (And other times when warnings were added in maintenance releases and caused people problems.)

But it would be awfully nice to be able to have new warnings when you want them. It would be easy enough to add a perl-version-added-at tag to new warnings, and have some way to specify what perl version you have tested your code at, like use warnings "version"=>5.8.3, and if everyone would keep to that standard, there would be no problems. But when running existing code, what do you assume the default version to be? And how would you specify that you want all warnings, regardless of what version they were introduced in?

Anyone have suggestions for a workable interface?

Comment on future warnings
Download Code
Re: future warnings
by Stevie-O (Friar) on Jul 09, 2004 at 00:10 UTC
    This sounds like a pretty good idea (and one that's possibly workable, at that!) One alternative would be to invert your logic. Instead of
    use warnings version => 5.008003;
    to only get warnings introduced at or before 5.8.3, perhaps a
    use warnings lastversion => 5.008003;
    to only get the relevant warnings introduced, and
    no warnings 'lastversion';
    as the opposite. This means that newer code will implicitly support the new warnings (because it lacks a 'lastversion' declaration), while retrofitting old code to inhibit the new warnings (in case it causes a problem) is one line added to the top of the file. The already-lexical nature of 'use warnings' should take care of the rest.
    --Stevie-O
    $"=$,,$_=q>|\p4<6 8p<M/_|<('=> .q>.<4-KI<l|2$<6%s!<qn#F<>;$, .=pack'N*',"@{[unpack'C*',$_] }"for split/</;$_=$,,y[A-Z a-z] {}cd;print lc
Re: future warnings
by BrowserUk (Pope) on Jul 09, 2004 at 00:12 UTC

    How about making it a build-time config setting? Overridable by a use warnings parameter.

    That way, people could specify that they don't want to see "just useful" warnings that didn't exist prior to some version. It wouldn't help those of us who use binary distributions, but we deserve what we get:)

    It wouldn't be too onerous to add the version => 'x.x.x' to existing scripts that suddenly start bellyaching. I would imagine that most shops run a new distribution in a test environment for a while before upgrading production servers anyway?


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
      What's a test environment?

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

        That's where you change stuff in production and quickly put it back before anyone notices you broke it!

        Cheers,

        -- Dave :-)


        $q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print
Re: future warnings
by hv (Parson) on Jul 09, 2004 at 03:26 UTC

    I think use warnings (and the -w flag) should continue to enable all warnings. It might be reasonable to add a new warnings option to enable a restricted set of warnings, but that would involve tagging each possible warning with a severity as well as a class, and the reason we have warnings is usually because we don't know how severe the problem is: if we did, we either wouldn't emit a warning at all, or we'd die. (Consider, for example, what severity the "use of uninitialised value" should be.)

    But, coming from the other side, I'm not convinced about the righteousness of "people [expecting] previously warnings-free code to stay that way when upgrading". For my own production code, if a new version of perl means my code emits a warning, that's a good thing - maybe there is a bug in my code I was never aware of, and if not it is usually little trouble to rework the code slightly to avoid the new warning. It is rare that a new warning isn't at least highlighting the fact that my code is doing something dubious, and I should be looking at it particularly carefully.

    Again, if you know your code is perfect, why leave warnings enabled at all? Indeed, many people prefer to turn warnings off at the point code is put into production.

    The real underlying problem, I think, is the granularity of the warnings pragma: almost always I want either all warnings, or all warnings except for this one. So I almost always have -w at the top of the script, and an occasional:

    { # add a block to minimise scope of fewer warnings no warnings qw/ thisone /; code that warns of thisone; }

    As long as access to warnings is restricted to functional classes, this does almost exactly the wrong thing: I need to disable the one warning I know the code emits, and I'm happy that in this case that warning does not reflect an error in my code. However the one type of warning this code is likely to emit that would represent a genuine problem is any other warning from the thisone class. (This I think is one point Yves was trying to make in one of his recent p5p postings about sprintf.)

    Perhaps, then, the right answer is for every warning to be tagged with an id, for an option to get the id shown when the warning is, and for the ability to lexically enable or disable individual warnings by id. However I am aware that this would involve a lot of work: as well as the effort involved in actually locating and tagging every current warning, the current implementation relies on propagating one bit for each specificiable class, and throwing around bitmasks with a bit for every conceivable warning would be unusably unwieldy.

    Similarly, reimplementing with a chain of individually specified warnings (presumably, in most cases a chain representing "enable all warnings but these") would work fine except when supporting the existing practice, which means every no warnings qw/ foo / would need to construct a chain of as many warnings as exist in that foo class, a big cost to all the existing code out there.

    I guess there must be some happy medium, which would allow efficient handling of both individual warnings and classes of warnings. And if such a medium can be implemented, I suspect that having introduced the ability to refer to individual warnings it should become much easier to specify new classes of warnings (such as "introduced in perl-5.8.3") that cut across the existing classes. And then we might have the best of all three worlds. :)

    Hugo

      I agree that all warnings should be enabled by default, even if this means that previously warning free code starts to complain.

      I would think of these new warnings as a free bit of peer review, rather than annoying. After all if there is a problem with production code I want it to be mentioned.

      If the code was warning free and you don't want new warnings then switch off warnings. You can switch it back on if you make changes in which case you are in a good position to address the new warnings.

      --tidiness is the memory loss of environmental mnemonics

      Why limit yourself to three worlds? Perhaps warnings should be considered to be like some kind of row in a relational table, and you can apply any selection criterion on any attribute of the data. Or consider a warning to be an object that decides whether or not to say anything based on the selection criteria it can see in its various outward lexical scopes. The actual selection criteria do not need to be physically replicated as long as you can follow the chain of criteria outward somehow. Bitmasks are merely a useful optimization for certain selection criteria.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://373005]
Approved by FoxtrotUniform
Front-paged by Courage
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2014-09-20 05:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (153 votes), past polls