ti at lemonia.org
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 london.pm