An interesting variation on the theme might be to ask when they would consider not using strict.

Hmm... that's an interesting question. So when would you?

When using strict would violate the "once and only once rule". Consider the difference between specifying a whole series of package names versus interpolating something in.

*GPMN::Database::Table::org::pre_insert =
*GPMN::Database::Table::user::pre_insert =
..... # repeat for another 15 tables and then do the same for ::pre_up
+date

for (qw[org user group foo bar]) {
    no strict 'refs';
    *{"GPMN::Database::Table::${_}::pre_insert"} = sub ....
    *{"GPMN::Database::Table::${_}::pre_update"} = sub ....
}
[download]

An interesting discussion on when it is or is not justified to break the rules starts at Re: Paradigm Shift - Don't use strict.

Yes, usage of strict.pm is discussed, but goto winds up discussed more.

Short answer: Extremely rarely.

Slightly longer answer:

If my application ran/tested cleanly with use strict, but the operational requirements were such that disabling it allowed those ORs to be met without further modification, when they were not met when it was in force.

Supplimentary question: Under what circumstances might this scenario be so?

My answer: I have yet to encounter one, but if I did, I would consider the option.

---

Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

In my extremely limited experience with Perl, I've only run into one place where I couldn't use strict; I had a module that was tracking multiple file locks using flock() and I was storing the various file handles in a hash. When I tried to close the files (and thus release flock()'s lock) I got an error about "using string substitution for symbolic table entries under strict" or some such thing. So I commented out the use strict; line and documented why, and forced that set of functions into its own module, never to be mingled with others.

So, I suppose, implicit in this story is that, for now, I wouldn't not use strict; unless it was required.

I'm probably misunderstanding your description as I couldn't create the error you describe, but maybe you were using an earlier version of Perl?

use strict;
open FH, '<', 'test1.dat' or die $!;
my %h; $h{FH}=FH;
flock( $h{FH}, 2);
close $h{FH}
[download]

That said, the only critisism of your approach I would have, and it's only from the "if your going to use strict, use it everywhere possible" point of view, is that as strict is lexically scoped, you can usually get away with something like

    ....
    {
         no strict 'refs';
         # do the thing that conflicts with strict.
    }
    ....
[download]

Which retains as many of the benefits of strict as possible for as much of the code as possible and adds an element of self documentation, which you could always add to if necessary. In your case, it would also remove the need for a seperate module if that meant an abitrary split in codebase.

To date, I haven't found a single time when I've wanted to drop strict, even at very localised level. Perhaps because every program I write starts life as a template that includes it. Maybe because I've never been a shell programmer and never used Perl before v5.6. Whatever the reason, I never even find myself going out of my way to avoid dropping it. The issue just never seems to come up. Then again, I think I've only used eval 2 or 3 times.

Maybe there is a whole world of simple, elegant solutions to difficult problems that I'm missing out on, but for now I'm happy in my ignorance of them:)

All of that said. If I ever encounter a situation where I needed to drop strict (locally), I wouldn't hesitate to do so if it made sense, especially if it avoided a convoluted work-around.

In essence, I agree with your answer:)

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller