Re^3: Use of $AUTOLOAD and strict

From strongest to weakest points:

@ARGV is always populated - it's the arguments you've been passed. If you don't have any arguments, the list is empty - which is precisely populated with what is passed in. @INC could similarly be empty, but I'm sure it would still be created. (Of course you'd have serious other problems if @INC were empty, but we won't go there.) More realistically, %ENV could be empty, but it would still be created because it would be populated - by nothing, but populated nonetheless. Think of code like this:

no strict;
@ARGV = ();
use strict;
print scalar @ARGV;
[download]

This wouldn't trigger the error - think of the first two lines as what perl does in the case of no arguments, and the latter two as representative of doing something with that nothing.

@_ is populated - and localised - for each function call. The perl runtime has to create this to populate it. You don't create it - perl does.

$_ is created with @_ by actually creating *_. But that's just a nit.

$a and $b are wierd exceptions. I can't explain those. Sorry.

Note also that these are variables that are created at compile time, not runtime. $AUTOLOAD, besides being local to each package that it deals with, is created at runtime.

Comment on Re^3: Use of $AUTOLOAD and strict Download Code

Replies are listed 'Best First'.
Re^4: Use of $AUTOLOAD and strict by ryantate (Friar) on May 13, 2005 at 21:52 UTC
Interesting. I must confess I have a little trouble discerning the difference between the creation and population of `$AUTOLOAD` vs. the creation and population of `@_` as you describe it. Except that you get an error for trying to use `$AUTOLOAD` without explicitly declaring it. And, obviously, it is only used for AUTOLOAD functions. Also, perl doesn't create it for you ... but that's the problem that started this whole talk, how do we know when perl creates it for you. But I'm no C programmer or system hacker, so I'm probably missing certain nuances ;-> Maybe the answer is that, "within a given package, perl does not always need to create `$AUTOLOAD`, but it does always need to create `@_`". It's pretty rare to not need `@_` but very common to not need `$AUTOLOAD`. It just seems weird to me that perl doesn't see `sub AUTOLOAD{` and automagically create and localize `$AUTOLOAD`. Seems arbitrary. Unlike `@_` within `sub`, `$AUTOLOAD` is always populated within `sub AUTOLOAD`. Sigh. I don't know why they didn't just make `$AUTOLOAD` the second param in `sub AUTOLOAD`, ie `my ($self, $autoload) = @_`. My head hurts.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Use of $AUTOLOAD and strict
by ryantate (Friar) on May 13, 2005 at 21:52 UTC

I must confess I have a little trouble discerning the difference between the creation and population of $AUTOLOAD vs. the creation and population of @_ as you describe it. Except that you get an error for trying to use $AUTOLOAD without explicitly declaring it.

And, obviously, it is only used for AUTOLOAD functions. Also, perl doesn't create it for you ... but that's the problem that started this whole talk, how do we know when perl creates it for you.

But I'm no C programmer or system hacker, so I'm probably missing certain nuances ;->

Maybe the answer is that, "within a given package, perl does *not* always need to create $AUTOLOAD, but it does always need to create @_". It's pretty rare to not need @_ but very common to not need $AUTOLOAD.

It just seems weird to me that perl doesn't see sub AUTOLOAD{ and automagically create and localize $AUTOLOAD. Seems arbitrary. Unlike @_ within sub, $AUTOLOAD is *always* populated within sub AUTOLOAD.

Sigh. I don't know why they didn't just make $AUTOLOAD the second param in sub AUTOLOAD, ie my ($self, $autoload) = @_.

My head hurts.

[reply]
[d/l]
[select]