It may be just "cargo cult".

perlsub says "most" routines would do it, but you don't "have" to.

from perlsub:

 Most AUTOLOAD routines will load in a definition for
 the subroutine in question using eval, and then execute
 that subroutine using a special form of ``goto'' that
 erases the stack frame of the AUTOLOAD routine without a
 trace.
[download]

note: I did think it was a performance issue - it is not.

Correctness, is good. But hiding where a routine was called from is not correct.

It may be, for certain values of "correct" :-)

If I autoload methods that log (as an example of use of) caller() information, I would not like seeing in my logs:

My::Lazy::method called from My::Lazy::AUTOLOAD
[... later ...]
My::Lazy::method called from Some::Other::method
[... and ...]
My::Lazy::method called from Yet::Another::method
[download]

While correct, in a sense of the word, the information given in the first of these lines is not useful. And I don't want to make AUTOLOAD smart enough to know what to do with caller information in every case. That would defeat the purpose of AUTOLOAD. And so, I use goto instead.

With goto, I get the caller information I would get if I were not using AUTOLOAD.

If your correctness criterion is that the sub should behave as if it was already in existence, and not autoloaded, then goto provides that correctness.

The Sidhekin
print "Just another Perl ${\(trickster and hacker)},"

Your argument seems weak because AUTOLOAD will be smart
enough to make the routine, but too stupid to know whether
to use caller itself.


If this is debugging info there is no reason to avoid logging
the AUTOLOAD call also. If it is not debugging info, I
don't see a reason to expose implementation details to
users.

I agree with The Sidhekin that correctness is an amorphous thing.

We agree on the important thing, but I feel I should clarify on the points where we don't seem to agree.

Your argument seems weak because AUTOLOAD will be smart enough to make the routine, but too stupid to know whether to use caller itself.

AUTOLOAD does not need to be smart in order to make the routine. It could be piecing them together from data provided to it (DATA handle, global variables, other functions). It can do this and still be dumb.

And though it may use caller, it need not know what the generated routine intends to do with this info. If each routine has its own needs, and AUTOLOAD needs to know it, using AUTOLOAD is a waste of time.

If this is debugging info there is no reason to avoid logging the AUTOLOAD call also.

Well, to avoid clogging the logs. If AUTOLOAD is called 30 000 times each day, but the select few routines we want to debug are called 20 times each day, it would be boring to leaf through that log. And a waste of disk space.

More, if several invocations of the same program log to the same file (as is commonly the case with CGI), it may not be easy to match the AUTOLOAD logging with the logging performed by the generated routine. While it can be done that way, you lose information.

If it is not debugging info, I don't see a reason to expose implementation details to users.

The routines generated need not just display the caller info. It could use it to provide different functionality (different access level or interface; whatever) depending on who called it.

So it is not just debugging info.

The Sidhekin
print "Just another Perl ${\(trickster and hacker)},"