Re^6: Shebang behavior with perl (-w)

I find tying warnings to blocks of code to just not be a great approach.

I'm following this thread with interest; and no firm conclusions yet. (And I just read your follow up.)

And I have an assertion/question/dunnu: Whilst warnings do tend to follow the data; doesn't their significance (benign or actionable) depend upon the purpose/function of the code manipulating that data?

Currently I favour -w in scripts and use warnings in modules.

I prefer -w explicitly because it let's me see warnings generated as a result of what I've passed to (other people's) modules I use -- when that is the cause -- and prompts me to check up on warnings the authors have ignored; where these occur at use time; and satisfy myself of their benign status or otherwise.

I like to see use warnings in modules (in preference to nothing), because it indicates to me the author has thought about it. I have no problem with no warnings at limited scopes.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Comment on Re^6: Shebang behavior with perl (-w)

Replies are listed 'Best First'.
Re^7: Shebang behavior with perl (scope) by tye (Sage) on Mar 03, 2015 at 07:10 UTC
Whilst warnings do tend to follow the data; doesn't their significance (benign or actionable) depend upon the purpose/function of the code manipulating that data? Either that, or the purpose of the code creating that data. Enabling or disabling some warnings at some localized scope can certainly be useful. The short-comings of warnings.pm are only partial. You could repair some of the shortcomings of warnings.pm by allowing subs to declare that they want string values or numeric values (well, for positional arguments), such that the conversion from scalar to string/number would happen in the context of the call to the sub rather than inside the sub when the arguments are extracted or even later when they are finally put to real use. You could also repair them by providing a way for a sub to request code to be run with the caller's warnings settings. Then a careful module author could go to the effort to "cast" any provided values to the more-specific type in a way that would only cause a warning if the caller wanted to hear that type of warning. `sub careful { my( $string, $number ) = @_; { use warnings ':caller'; $string = "$string"; $number = 0+$number; } ... }` [download] You could also put the onus on the author of the calling code. This doesn't make much sense to me in the case of the caller not wanting warnings, but I can see it making sense when the caller wants warnings but the called sub doesn't have warnings enabled: `use warnings; ... sloppy( "$string", 0+$number );` [download] These relatively few data-specific warnings might be rather insignificant if it weren't for the fact that "uninitialized" warnings are probably the single most common warning both in terms of how likely they are to happen and in how often people want to ignore them. Though, I'm not advocating for such feature enhancements to Perl. I'm happy with my "-w" and (newly adopted) "-X". - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^7: Shebang behavior with perl (scope)
by tye (Sage) on Mar 03, 2015 at 07:10 UTC

Whilst warnings do tend to follow the data; doesn't their significance (benign or actionable) depend upon the purpose/function of the code manipulating that data?

Either that, or the purpose of the code creating that data.

Enabling or disabling some warnings at some localized scope can certainly be useful. The short-comings of warnings.pm are only partial.

You could repair some of the shortcomings of warnings.pm by allowing subs to declare that they want string values or numeric values (well, for positional arguments), such that the conversion from scalar to string/number would happen in the context of the call to the sub rather than inside the sub when the arguments are extracted or even later when they are finally put to real use.

You could also repair them by providing a way for a sub to request code to be run with the caller's warnings settings. Then a careful module author could go to the effort to "cast" any provided values to the more-specific type in a way that would only cause a warning if the caller wanted to hear that type of warning.

sub careful {
    my( $string, $number ) = @_;
    {
        use warnings ':caller';
        $string = "$string";
        $number = 0+$number;
    }
    ...
}
[download]

You could also put the onus on the author of the calling code. This doesn't make much sense to me in the case of the caller not wanting warnings, but I can see it making sense when the caller wants warnings but the called sub doesn't have warnings enabled:

use warnings;
    ...
    sloppy( "$string", 0+$number );
[download]

These relatively few data-specific warnings might be rather insignificant if it weren't for the fact that "uninitialized" warnings are probably the single most common warning both in terms of how likely they are to happen and in how often people want to ignore them.

Though, I'm not advocating for such feature enhancements to Perl. I'm happy with my "-w" and (newly adopted) "-X".

- tye

[reply]
[d/l]
[select]