AUTOLOAD

[Tim Sweetman]

Simon Cozens wrote:

> Tim Sweetman:
>>Damian Conway provides Class::Std, but then advises against use of 
>>either AUTOLOAD or AUTOMETHOD. Several people appear to disagree with 
>>him, though they haven't (here) said why...

> But I have said why, you even responded to it, here, look:

>>For a start, "can" returns potentially random output for a given method. 
>>This is affecting the interface. 

> By interface, I mean "contract"; the interface that the programmer uses.
> Adding an AUTOLOAD does not change what methods an external programmer ought
> to be calling if he's honouring the contract; only changing the documentation
> does that.   If your user is not honouring the contract, that, rather
 > than AUTOLOAD, is the problem.

Perl programmers are advised to use two-argument bless (bless $foo, 
$class) precisely because this facilitates inheritance.

Very likely, nowhere in the documentation does it say "oh, this module 
has been written using two-argument bless, so you can extend it". Use of 
two argument bless is, I think, implicitly expected as the sort of thing 
a competently written, OO Perl module would do.

So. I think your arguments in favour of autoload are:

1. Code with AUTOLOAD is more readable.
2. If you didn't read the docs carefully enough, or relied on something 
that wasn't in the docs, that's your fault.

Aim 1 ought to be about code being clear and unambiuous; aim 2 seems to 
be about ducking responsibility in case of ambiguity. I'd have thought 
being able to see what the code did, with a minimum of "what about when 
THIS happens, in THAT order?" hypothesis testing, was part of readability.

>>Then again, AUTOLOAD is quite happy to snaffle someone else's interface 
>>from within the inheritance hierarchy.

> This, of course, is untrue.

Specifically, a child's AUTOLOAD will block a parent's AUTOLOAD, and 
there is no convention for passing AUTOLOAD requests between AUTOLOADs 
(equivalent of the ->SUPER::* or ->NEXT::* invocations for passing 
ordinary method calls up the inheritance tree).

(Granted, in practice, classes tend to be fairly tightly coupled to 
their parents & children, and only extreme caution, ferocious test 
suites, or both, allow refactoring of individual classes, ie. changes 
within those classes with no effect on other classes outside the interface).

Tim