Front page | perl.perl5.porters |
Postings from March 2000
From: M.J.T. Guy
March 16, 2000 01:03
Message ID: E12VWBR-0000gKfirstname.lastname@example.org
Ilya Zakharevich <email@example.com> wrote
> Nope, they have two roots: this one, and that you cannot run some
> action when an undefined subroutine is seen at *compile* time.
It's all a matter of how you look at it. My interpretation is
"If AUTOLOAD had been defined to return a ref in the first place,
then of course it would have been used at compile time." But of
course, that's re-writing history.
> See my proposal on 'use autoload'.
Where can I find that? All I could find in the archives is
which is, err, short on detail.
> No new magic names, please! In my proposal what you want would be
> installed by
> use autoload body => \&AUTOLOADREF;
As I said in my proposal, I'm not keen on new reserved names either.
But I don't see a better alternative. What goes on inside your
"use autoload"? Where is the user-provided subroutine stored?
Unless it's in some user-visible variable or glob, it has to be hidden
in some new extension to the guts.
Additionally, having a user visible subroutine makes it easy to
export and/or inherit. And most autoload subroutines are
either imported or inherited. Also it's easy to do things like
"try my loading procedure; otherwise pass the problem over to
> But there is an additional (and separate!) callback to be called at
> compile time:
> use autoload proto => whatever;
As my scheme has. But I have one subroutine with flags where
you have several. I thought that would be most convenient in the
common case where you want all the variants to do the same thing,
i.e. load the subroutine and return the reference.
Clearly one could convert back and forth between the two styles.
But it looks like your approach and mine have a lot in common. Is
that "Great minds think alike" or "Fools never differ?" :-)