[% setvar title Standardise Function Pre- and Post-Handling %]

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

Standardise Function Pre- and Post-Handling

VERSION

  Maintainer: Jarkko Hietaniemi <jhi@iki.fi>
  Date: 5 Sep 2000
  Mailing List: perl6-language@perl.org
  Number: 194
  Version: 1
  Status: Developing

ABSTRACT

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.

DESCRIPTION

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.

IMPLEMENTATION

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]?

REFERENCES

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