Strict is a compile time thing - not run time. Scoping like "my vars" is a big part of what "use strict" enforces - use of a fully qualified name in another module is completely within the "rules of strict".

I would highly recommend Randal Schwartz'es book, "Effective Perl Programming", see item 36. For example to learn more about -w, see page 143.

I don't think we need to get into a big brouhaha about legalistic sounding terminology about "discouraged" vs "deprecated". Suffice it to say that neither of us would recommend old style &sub() over just sub() for new code.

I didn't explain var passing very well, fair enough. I can write an article about this if there is enough interest. There are limits to what can be explained in a short post. And there are some extremely complex things that have to do with this. But yeah, in general when you call a sub, you push things onto a stack and the sub consumes them by shifting them off the stack, just like with any other main programming language, C, C++, JAVA, etc. Yes, there are things that are different things about say how C and C++ and Perl does this, but these are details. The basic "model" about how to send stuff to a sub and get stuff back is the same.

I don't think that there are any at all.

See warnings.

Strict is a compile time thing - not run time.

The strict documentation disagrees:

"strict refs" ... generates a runtime error if you use symbolic references (see perlref).

Scoping like "my vars" is a big part of what "use strict" enforces....

As I wrote in my previous message, you can avoid lexical variables altogether (and avoid lexical scoping altogether) and satisfy strict. Did you try it? You can also declare all of your lexical variables at package-level scope and satisfy strict. strict has nothing to do with scoping (except that strict's area of effect is lexical).

... in general when you call a sub, you push things onto a stack and the sub consumes them by shifting them off the stack, just like with any other main programming language....

I can think of multiple machines -- virtual and otherwise -- where that's not true.

I was not precise regarding strict and warnings. Neither one of these things is purely compile time or run time.

"strict" has 3 categories:
- refs
- vars
- subs

'refs' has to do with symbolic references and YES, is a runtime warning. The other two: vars and subs are compile time checks. Far and away the most frequent thing that I see with "strict" is a 'vars' error, problem. 'subs' just disallows barewords.

my $ref ="foo"; #symbolic reference to some global variable
print $$ref;    #this sort of thing is what strict 'refs' won't like
[download]

I would argue that although this check happens at runtime, the use of symbolic references is so seldom and what Perl does to check this is so fast that this is just lost in the overall performance scheme of things. Essentially if you don't have any symbolic references, checking happens at compile time. I think one would be hard pressed to find any program what runs significantly slower when "using strict;"

On the other hand "use warnings;" turns out not to be purely runtime either. There are some compile time aspects to this in addition to the run time checks. However the "main event" are the runtime checks. And there are a whole bunch of them! Take a gander at the section on warnings in Chapter 31 of "Programming Perl", the is a cool diagram showing the categories.

I have read that performance hit could be as much as 30% in some outlier cases with "use warnings". I personally have not spent a lot of time worrying about this or benchmarking code, because I feel that the benefits of using both strict and warnings outweigh any kind of performance hit entailed.

So I guess the most accurate statement would be that "use strict" happens mainly at compile time and "use warnings" happens mainly at runtime.

#!/usr/bin/perl --

my $f = undef;

print "$f\n";
use warnings;
print "$f\n";
no warnings;
print "$f\n";
__END__

Use of uninitialized value in concatenation (.) or string at - line 7.
[download]

Great illustration of the point! If warnings are enabled, printing an "undef" value will generate an error when the code runs. Unlike C or C++, Perl has a notion of a "not yet defined" variable and in many ways this works to HUGE advantage, like assigning a new hash key/value combo, you can just do it without needing to check whether the key exists already or not...the key will be created if it doesn't exist.