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)},"

You are right in correcting my statement with your clogging
logs point. I was trying to express that debugging code does
not follow the normal rules of proper/good/correct coding.
It is equally easy to imagine a name-conflict where you
mistakenly call a defined routine thinking you were AUTOLOADing
it. Then instrumenting your code the other way could be
more helpful.
Or that your other thirty thousand AUTOLOAD calls result
in logging indirectly.


You gave me a laugh, thanks.


I don't believe you think that using caller to
implement access control or interface selection is a reasonable
idea. I don't believe that even though you just said it.

I don't believe you think that using caller to implement access control or interface selection is a reasonable idea. I don't believe that even though you just said it.

I know that kind of trick has been used to implement something like private or protected methods; I would rather not debate if it is reasonable or not.

What I have done is use caller information to decide how a routine behaves, so that if caller()->isa("Picky::Class"), the data passed is handled ... slightly differently.

What can I say? It seemed like a reasonable idea at the time.

... and it has worked without redesign for years now :-)

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