| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Standardise Function Pre- and Post-Handling
Maintainer: Jarkko Hietaniemi <jhi@iki.fi> Date: 5 Sep 2000 Mailing List: perl6-language@perl.org Number: 194 Version: 1 Status: Developing
A standardised way of registering/unregistering/inspecting pre- and posthandlers (also known as hooks) for handlers, and possibly also for code references any, is needed.
NOTE: this RFC does not (yet) propose any particular syntax or interface. Its main purpose for now is to point out the potential for standardising, and to outline the required functionality.
Many modules [PV:HPPC, JP:HWS, MJD:M] introduce their own way of either installing/uninstalling generic function handlers [PV:HPPC, JP:HWS] or installing/uninstalling specific function handlers [MJD:M]. With the more generic approaches one can wrap a function to a chain/stack of pre- and post-handlers: pre-handlers can do anything they want to the argument list; post-handlers can do anything they want to return value list. To the caller of the original function there is (should be) no difference. The [MJD:M] is a special-purpose prehandler: it caches the return values for idempotent ('pure', side-effect-free) functions, using the arguments as the key to to the cache, after the initial call fetching the return values from the cache, resulting in a (hopefully) saved computation and faster function calls.
All the above support registering and deregistering handler functions for functions, but in more general case it should be possible to do the same for code references. This would be much more orthogonal, and also kind of mandatory if core functions become referenceable as [JV:RFC168] proposes. This would open up a way towards very nifty features like the ubiquitously-requested URL-aware open(). Just install your URL-ware prehandler to \CORE::open and off you go. Want versioned files? warn() that also transparently does syslog()? close() that automatically renames the file to file.YYYYMMDD-hhmmss after it has been closed?
Prehandlers should stack as BEGIN blocks do; posthandlers should stack in the reverse order as END blocks do.
There should be a way inspect the pre- and post-stacks of handlers, and the all handlers should have a symbolic name. For example, a handler X may want to install before another handler Y but after another handler Z. A meta-handler may want to remove a handler.
The implementation is dependent on what happens to typeglobs in Perl 6, how does one inspect and modify the moral equivalent of the symbol table? Also: what will become of prototypes? Will it become possible to declare return types of functions?
As pointed out in [JP:HWS] certain intricacies are involved: what are the semantic of caller()? Should it see the prehooks? If yes, how? How does this relate to the proposed generalized want() [DC:RFC21]?
RFC 21: Replace wantarray with a generic want function, by Damian Conway
RFC 168: Built-in functions should be functions, by Johan Vromans
Hook::WrapSub by John Porter, search.cpan.org
Memoize by Mark-Jason Dominus, search.cpan.org&query=Memoize
Hook::PrePostCall by Philippe Verdret, search.cpan.org