Tim Sweetman ti at
Mon Jan 15 22:28:48 GMT 2007

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).


More information about the mailing list