#ifndef _ankh_h
#define _ankh_h
/* Creation and Destruction */
/* $Id: ankh.h,v 1.1 2001/10/17 18:00:19 eddy Exp $ */
#include "tot.h"
extern record Ankh;	/* which is both the initialiser and the interface:
			   its how is an ask. */

/* Preamble.

   Heap objects must, necessarily, support a lookup in response to which they
   will return their `cease existing' method.  This is what gets invoked when
   all references to the object have been dropped: it is the raw mechanism
   around which one wraps a reference-tracking system of one kind or another.
   While I shall probably attempt a rather strange one of these, python's plain
   reference-counting scheme will do for tracking: I want the toy framework to
   be open enough that it could incorporate memory memory managers using various
   schemes and let them interoperate.

   A non-heap object, asked for its destructor, may sensibly either return a
   no-op destructor or fail to recognise the destruction interface: in either
   of these cases, something trying to exercise a destructor should do nothing.

   We can ask an object for its destructor in two forms: one is the `just get
   on and invoke it now', the other is `fill in this naked object (used as key)
   as a record which, when invoked, will do the job'

   A module will ask the memory manager for a source of objects: to do so it
   will need a naked size_t (either when asking for the source or on each use of
   the source) and an interface which means `give me a source of things this
   big'.  The source must support an interface which asks `what is the
   destructor for objects I get from you' - this will generally be asked for
   during module initialisation, directly after acquiring the source, and
   recorded somewhere visible to the rest of the module.  It may, however,
   support the same effect (which is what matters) by providing a lookup to
   which the .how of my objects can delegate - then, though my .how doesn't
   explicitly support the destructor interface, my object gets built-in support
   for its destructor - and, indeed, for any other interfaces the memory manager
   cooks up (e.g. reference tracking).  Note that the memory manager may be
   incurring an overhead on your object - a few bytes just before the address to
   which it gives you a pointer, in which to keep accounting information, say -
   in which case it needs to be confident that any address you pass to the
   lookup of its delegator will genuinely be some address it returned to you
   (and on which you haven't since invoked destructor).

*/

/* Interface: use of Ankh.how as the key to an object's lookup.

 */

/* This is what other compilation units use to get a creator ... */
extern record new_creator(status *up, record init, size_t big);

/*
  $Log: ankh.h,v $
  Revision 1.1  2001/10/17 18:00:19  eddy
  added in all files previously missing from RCS

  Revision 1.2  1998/12/15 21:46:13  eddy
  Tuesday dinner-break.  Revolution coming.

  Initial Revision 1.1  1998/12/15 15:32:03  eddy
*/
#endif /* _ankh_h */