[% setvar title Replace AUTOLOAD by a more flexible mechanism %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

TITLE

Replace AUTOLOAD by a more flexible mechanism

VERSION

  Maintainer: Ilya Zakharevich <ilya@math.ohio-state.edu>
  Date: 15 Sep 2000
  Mailing List: perl6-language@perl.org
  Number: 232
  Version: 1
  Status: Developing

ABSTRACT

This RFC proposes two-stage autoloading: one stage may be registered to act when the symbol is encountered at compile time, the other when the subroutine is called. Autoloading on the second stage does not call the subroutine, only loads it.

DESCRIPTION

AUTOLOAD interface was created before closures were available. Because of this, it combines two actions into one call: it loads the subroutine, and calls it.

This two actions should be separated. Additionally, some action may be needed during compile time. For example, one may fetch the prototype of the function, or even call the function, so that its (constant) value may be used in this and other calls.

[WIth the current implementation all the prototypes should be loaded no matter what, with significant memory and time overheads.]

When a symbol for an undefined subroutine is seen at compile time, the proto action is invoked. It should return undef if no such symbol could be autoloaded (so that the symbol may be searched further in the @ISA tree). It should return the prototype if the symbol could be found. This call may have arbitrary side effects, such as defining the subroutine, or even calling it (useful for constant XSUBs).

When an undefined subroutine is about to be called, the load action is invoked. It should return a reference to a subroutine, or undef to signal that search should be continued further in the @ISA tree.

In both cases, the argument for the action is the name of the subroutine. If the subroutine has two different names (it was created with one name, and was imported with a different name), both names are provided.

The proto and load subroutines may be registered (both or any one) with the pragma

  use autoload ':proto' => sub {}, ':load' => sub {};

MIGRATION ISSUES

None.

[The current AUTOLOAD mechanism saves creation of a subroutine frame, since the actual call to the subroutine may be done via goto. If this is proved to provide some advantage, AUTOLOAD mechanism may be preserved as well.]

IMPLEMENTATION

Straightforward.

REFERENCES

None.