Re^10: Modules for autogenerating accessor/mutator methods

I see your point, but I find it interesting that one of Perl's standard modules, AutoLoader, is there precisely to support the loading of subs upon first use.

Which prompts the question: why does Perl actively support such a problematic feature? Two possible explanations come to mind: (a) lazy loading of subs was a bad idea from the start (for the reasons you describe), and future versions of Perl should get rid of it; or (b) there are a few rare instances in which the benefits of lazy loading outweigh its drawbacks, hence Perl supports it.

If I know anything about Perl culture, then I'd guess that (b) is by far the more likely explanation of the two, and I'm left to imagining what those "few rare instances" may be like. The only situation I can envision in which lazy loading may be desirable (despite its drawbacks) is one in which the possible methods are vastly more numerous than those that are actually used by any application. But this is all theoretical, since I don't recall ever using a module that fit this description.

Update: Just to be clear: I'm not presenting the existence of AutoLoader or its presence in the core as a veiled argument in favor of anything. I am genuinely interested in the question of why it's in the core in the first place: was it a mistake, or is it there because there are some legitimate (even if rare) uses for it?

the lowliest monk

Comment on Re^10: Modules for autogenerating accessor/mutator methods

Replies are listed 'Best First'.
Re^11: Modules for autogenerating accessor/mutator methods by diotalevi (Canon) on Jun 05, 2005 at 04:17 UTC
Oh hold on. You're drawing some very sharp lines around some issues where things aren't so clear cut. My argument for avoiding AUTOLOAD for normal method is based on the ideas of minimal surprise, minimal complexity, and removal of potential features from future use. You are increasing the changes that someone is going to be confused when working with your code because now the absense of a method doesn't mean it won't be handled and doesn't mean that the method isn't considered "implemented." So instead of an interface which appears one way and really is that way, you create an interface that only comes into existance when you use it. This is a kind of a trust fall - you can't see what's there to catch you and you hope it exists. You are adding additional code at runtime that may fail or introduce some sort of bug, perhaps depending on some unexpected state of the program. When you defer method creation until runtime, if something goes wrong, you won't know this until the method is already being called, not prior or during script compilation. Also, if you write code with bugs in it (of course not you. I mean your co-worker.), maybe you've accidentally caused the creation of your method to be dependant on something that might change in a runtime. So maybe its mutable. Maybe even non-deterministic. You've just reserved AUTOLOAD for this use and now you can't use it for something else. You didn't need to use AUTOLOAD but you did anyway. Well now that you want to use it for delegation, you either have to accomodate both your method creation and delegation in the &AUTOLOAD sub or just punt and note that now its impossible to use AUTOLOAD for delegation. Lastly, I don't think the presence of AutoLoader.pm in the core is an argument worth making. No one really uses it anymore and I'm not sure that using it wouldn't be a mistake for most people. I swear, I just grepped my local mirror of CPAN and came up zero modules that use it. I'm re-unpacking CPAN to see if I had just grepped a partial result or something. Update: Re-unpacking things helped. There are modules that use this. I'll even give you a list in a few minutes. `font_ft2_0.1.0 gpib-0.30 parrot_0_0_7 parrot-0.0.8 sepia vgalib ARSperl-1.82 Epeg File-LibMagic-0.82 Finance-Currency-Convert-1.04 Image-EXIF-1.00.3 Net-Divert-0.01 Net-NISplusTied-0.0 Parallel-Pvm-1.3.0 Xforms4Perl-0.8.4` [download]	[reply] [d/l]
Re^12: Modules for autogenerating accessor/mutator methods by wazoox (Prior) on Jun 05, 2005 at 07:49 UTC
Interesting... Your explanation of the drawbacks of AUTOLOAD reminds me of the drawbacks of exceptions, as presented by Joel Spolsky and Raymond Chen.	[reply]
Re^11: Modules for autogenerating accessor/mutator methods by tilly (Archbishop) on Jun 05, 2005 at 04:11 UTC
I'd hazard that the reason is (c), that it wasn't obvious how people would want to use the nice OO features, and their first guess was wrong. Some day I should go back to Class::AutoloadCAN and fill it out properly (add better support for inheritance, add something like Class::Privacy to give people public, protected and private methods...). I think that that is a better way to do what AUTOLOAD is used for.	[reply]