To my way of thinking, constructs such as use strict and use warnings are nothing more and nothing less than “ways to flip compiler-switches, which are considered only ‘at compile-time.’” They are strictly applied at compile time, to the limited extent that languages such as Perl possess a concept of “compile time,” and specifically do not influence the run-time behavior of the code.
Wrong. The effect of warnings is at runtime. Would you please read just a tiny bit of the perl documentation? Read perlrun. It states:
-c causes Perl to check the syntax of the program and then exit without executing it.
So, no runtime with -c .
#!/usr/bin/perl
# line 1 w.pl
use warnings;
my $a;
print $a;
qwurx [shmem] ~> perl -c w.pl
w.pl syntax OK
No warning.
qwurx [shmem] ~> perl w.pl
Use of uninitialized value $a in print at w.pl line 4.
Warning at runtime
As for the rest of your post - it is completely ass-backwards. The "original programmer" of an arbitrary package can never know how and where his package is used. And if I use a package, I am free to use it in a way that suits me, and not the intentions of the "original programmer". I have to regard the intentions of the "original programmer", who instead completely ignores my intentions, and there is no way I can impose something upon them.
To me, your idea introduces into the source-code many side-effects that are difficult if not impossible to discern from any simple reading of the source-code alone.
This is plain FUD. Which side-effects? You can't tell because maybe you are unable to read the code, and too self-impressed by your imagined vast expertise, that you deem it unnecessary to read the documentation. Read perlpragma. Read perlrun, perlsub, perlmod. Then you can actually understand which side effects this pragmatic pragma has. And name them, substantiating your claim.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
|