Search                        Top                                  Index
REF FLAVOURS                                   Mark Rubinstein  May 1986
                                             Revised A.Schoter June 1991

        COPYRIGHT University of Sussex 1986.  All Rights Reserved.

<<<<<<<<<<<<<<<<<<<<<                             >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<    THE FLAVOURS PACKAGE     >>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<                             >>>>>>>>>>>>>>>>>>>>>>

This document  provides details  of the  current implementation  of  the
flavours library package  and describes the  procedures and  identifiers
that are part of it. For an  introduction to the package and details  on
how to use  it see TEACH * FLAVOURS.  It is assumed  that the reader  is
familiar with the  details of the  package provided by  the teach  file.
Some notes on the implementation are given at the end of this file.

         CONTENTS - (Use <ENTER> g to access required sections)

  1   Flavour Objects
      1.1   Methods and Method Records
      1.2   Instances
      1.3   Flavours
      1.4   Flavour Records

  2   Flavour Definition
      2.1   Flavours and Sections
      2.2   SYSFLAVOUR

  3   Instance Creation

  4   Message sending

  5   Procedures and identifiers used by the FLAVOURS system

  6   Some implementation details
      6.1   Dynamic instance variables
      6.2   Lexical Instance Variables

  7   Precedence Ordering
      7.1   Messages
      7.2   Message Reception
      7.3   Method Selection
      7.4   Delayed Compilation

  8   Bugs and Omissions

1  Flavour Objects

There are four kinds of objects  of note in the flavours package.  These
are instances, flavour records, methods and method records.

1.1  Methods and Method Records
Methods are always procedures and a method record is a two field  record
for holding the procedure  and its name. Users  can make method  records
using  consmethodrecord   (q.v.)  and   access  parts   of  them   using
m_methodname and m_methodpdr (q.v.).

1.2  Instances
Instances  are  records  which  have  a  pointer  to  a  flavour  record
(instances can only have one flavour at a time) and a vector holding the
values for  the instance  variables. Instances  in fact  have two  value
vectors, one for the value of lexical instance variables and one for the
value of dynamic instance variables. Applying an instance to a word  has
the affect of sending the word as  a message to the instance, since  the
class_apply  (see  HELP * CLASSES)   of  instances   is  the   procedure
syssendmessage (q.v.).

1.3  Flavours
Flavours are  instances  of  the  flavour  metaflavour  or  one  of  its
subclasses. The metaflavour (see HELP * METAFLAVOURS) of all flavours is
the flavour "metaflavour". This is the user interface to classes --  the
instances of  metaflavours  are  constructed by  sysflavour  (q.v.)  and
cannot be created  by make_instance  or the  message "new".  One of  the
instance variables  of  all flavours  is  the "flavour_record"  -  which
should always be the value of the internal record which has the  details
of the class.  It should always  be possible to  get the  flavour_record
from a flavour  by applying ivalof  (q.v.) to the  flavour and the  word
"flavour_record". You could declare a procedure for getting the record:

    vars flavour_record_of = ivalof(%"flavour_record"%);

so that you can do

    flavour_record_of(metaflavour_flavour) =>
    ** <flavour_record metaflavour>

1.4  Flavour Records
Flavour records  are the  internal records  that hold  the details  of a
class. They cannot be constructed or altered by users, and for the  most
part people programming in FLAVOURS using the syntax provided need never
see or know  about flavour_records. However  if you wish  to bypass  the
syntax then it is necessary to be able to access the flavour records  to
pass as parameters to some  of the procedures. The procedure  sysflavour
(q.v.) returns a flavour record as a result. You can also access flavour
records by accessing the instance variable "flavour_record" of a flavour
(as shown above).

2  Flavour Definition

The definition of flavours is slightly different from that of most other
structures in POPLOG (with the possible exception of * SECTIONS) in that
when you define a flavour the dictionary is first searched to find  if a
flavour by the same name has already been defined. If one is found  then
that flavour is altered instead of a new one being created.

Using the flavour  definition routines  you can  define and  add to  the
definition of a flavour. The system will support full dynamic alteration
to flavours  -  the  adding  and removing  of  components  and  instance
variables and the adding  removing and changing  of methods, however  at
the moment the flavour definition procedure (sysflavour) and the  syntax
form (flavour..endflavour) will only add components, instance  variables
and methods, and change methods. If you  wish to remove any part of  the
definition then you must do so  by communicating with the flavour.  This
is    described     below     and     in     HELP * METAFLAVOURS     and

2.1  Flavours and Sections
Whenever a new  flavour is  created (because  no previous  one has  been
found) a dictionary  entry (a word  constructed of <name>_flavour  where
<name> is the name of the flavour)  is created and is given the  flavour
as its * valof. The only way that users can ensure that an entirely  new
flavour is created is to * cancel the word from the dictionary. The  use
of valof on  the constructed  word ensures  that the  flavour system  is
sensitive to sections. At present a flavour is always made * global so a
flavour is shared by the section it is defined in and all sections below
it. If the word <name>_flavour is exported from a section then the whole
flavour is effectively exported and made available to the section  above
the current one and all sections below the section to which the word  is

Flavours are defined using the procedure sysflavour the use of which  is
described more fully below. The procedure decides whether to build a new
flavour or alter an existing one on the basis of the name (as  described
above).  Since   many   details   of  flavours   and   their   inherited
characteristics are  "cached" in  the  flavour record  sysflavour  looks
after re-caching the characteristics for both the flavour being  changed
and any sub-classes that rely on it.

3  Instance Creation

Instances are created by  sending the message  "new" to the  appropriate
metaflavour (e.g. to create an instance of person:

    person_flavour <- new

will return the instance).

The procedure make_instance  described below provides  a good  interface
for creating and initialising instances.

4  Message sending

Messages can be sent  to an object  using the syntax  forms "<-" or  "^"
described below. The procedure for sending a message is "syssendmessage"
and the  details  of how  messages  are  received is  described  in  the
implementation section at the end of the file.

5  Procedures and identifiers used by the FLAVOURS system

<-                                                  [procedure syntax 4]
        Syntax for sending a message to an object. The format is

            object <- message(arg1, arg2, ... argn);

        For a message with no arguments you can do

            object <- message;

        For an update message the form is

            new-value -> object <- message(arg1, .. argn);

        This syntax uses syssendmessage.

^                                                   [procedure syntax 4]
        Syntax for sending a message to "self". It can be thought of  as
        a macro  where  "^" replaces  "self  <-" which  is  functionally
        equivalent, but  using  ^  can  be  more  efficient  as  dynamic
        instance variables do not need to be set and saved.

consmethodrecord(procedure, word)                            [procedure]
        Returns a  method record  (as required  by sysflavour  q.v.)  in
        which procedure is  the method  to be executed  for the  message
        word. If  the procedure  wants to  refer to  a lexical  instance
        variable then it should refer to them by doing

            ivalof(self, <instance-variable-name>)

        (This also  works  for dynamic  instance  variables but  is  not
        necessary within a method.)

        To construct  a method  to  be used  as  an updater  you  should
        construct a method record in which the procedure slot is  itself
        a method record and its name slot is the word "updater". E.g.

            consmethodrecord(consmethodrecord(PDR, NAME), "updater")

default_method                                                  [syntax]
        A special, optional modifier for defmethod (see REF * DEFMETHOD)
        which allows  methods to  be defined  for handling  cases  where
        there is no specific method for the given message. The  standard
        default method provided by vanilla_flavour prints a message (see
        Method Selection below), but it is possible for the user to  add
        default  methods   specific   to  their   own   flavours.   (See

defmethod method_name (args)                                    [syntax]
defmethod type method_name (args)
defmethod updaterof method_name (args)
defmethod type updaterof method_name (args)
        Syntax form for defining a method -- can only be used within the
        flavour..endflavour syntax form. It is used just like the syntax

        The type  argument is  option  and must  be either  "before"  or
        "after", indicating  that the  method  is to  be a  daemon.  The
        keyword "updaterof"  is  also option  and  is used  to  define a
        method to respond to an updater. (Using a combination of the two
        indicates a daemon  to be  activated on an  update messsage  see
        example 3)  method_name is the name of the method being defined,
        and args are the option arguments to the method.


            1.  A simple method:

               defmethod birthday;
                  age + 1 -> age;

            2.  A method with an output:

               defmethod distance_from(x, y) -> dist;
                    lvars x y dist;
                    sqrt(((my_x - x) ** 2) + ((m_y - y) ** 2)) -> dist;

            3.  A complex method definition:

               defmethod before updaterof location;
                   location <- player_leaves(self)

        See TEACH * FLAVOURS for  full details of  the flavour  package,
        including details  of  usage.  See  also  HELP * DEFAULT_METHOD,

divars word1 word2 ... wordn;                         [syntax procedure]
        Syntax word for declaring  dynamic instance variables. Can  only
        be used within the flavour..endflavour form. Its use is  similar
        to that of vars or lvars, e.g.

            divars name age occupation;

        You can also specify a default  value using the "=" syntax.  The
        value will be evaluated at compile  time and not at the time  of
        assigning the default values e.g.  the first but not the  second
        form will work.

            divars my_x = 10, my_y = 20;
            divars my_x = 10, my_y = my_x * 2; ;;; THIS WILL NOT WORK

enddefmethod                                                    [syntax]
        The syntax word enddefmethod  is used to  indicate the end  of a
        method definition. See also REF * DEFMETHOD

endflavour                                                      [syntax]
        The syntax  word endflavour  is used  to indicate  the end  of a
        flavour definition. See also REF * FLAVOUR

flavour name                                          [syntax procedure]
flavour name a metaflavour
flavour name novanilla
flavour name a metaflavour novanilla
flavour name isa component_1 ...
flavour name a metaflavour isa component_1
flavour name novanilla isa component_1
flavour name a metaflavour novanilla isa component_1
        flavour is  a syntax  word  used for  defining or  altering  the
        definition of a flavour object, while using the FLAVOUR library.
        The heading has the key word  flavour  followed  by the name  of
        the flavour to be  defined or altered.  You can then  optionally
        specify its metaflavour (e.g. a  mixin), the default is for  the
        metaflavour to be  flavour. There  is then  an optional  keyword
        "novanilla" meaning  do  not include  the  vanilla_flavour  as a
        component flavour optionally followed by the key word "isa"  and
        a list of names  of flavour which are  to be components of  this
        flavour. The body of the flavour can contain method  definitions
        (see REF * DEFMETHOD), procedures  and declarations of  instance

        For example:

            flavour person novanilla;
            ivars name age sex;
                defmethod birthday;
                    age + 1 -> age;
                    [happy birthday to ^name] =>
                defmethod printself;
                    pr('an object called '); pr(name);

        Or you might want to have a flavour called student that is a sub
        class of person;

            flavour student isa person;
            ivars subject tutor;
                defmethod graduate;
                    [congratulations] =>
                defmethod crawl:
                    [^subject is fascinating] =>


flavour_flavour -> metaflavour                     [variable -- flavour]
metaflavour -> flavour_flavour
        The default system metaflavour (see HELP * METAFLAVOURS).

flavour_of(word) -> flavour;                                 [procedure]
        Returns the flavour associated with the word (its name). Returns
        false if it cannot find one in the current section. Does not try
        to autoload.

isinstance(object, flavour) -> boolean;                      [procedure]
        Returns false iff  object is not  an instance of  flavour or  an
        instance of a flavour that inherits from flavour. In other words
        checks if object has the properties associated with flavour.  If
        flavour is false then returns true iff object is an instance.

ismethodrecord(methodrecord) -> boolean;                     [procedure]
        Returns true iff methodrecord is a method record.

ivalof(instance, word) -> value;                             [procedure]
value -> ivalof(instance, word);
        Access or updates the instance  variable slot named word of  the
        object instance. An error  occurs if there  is no such  instance

ivars word1 word2 ... wordn;                          [syntax procedure]
        Syntax word for declaring  lexical instance variables. Can  only
        be used within the flavour..endflavour form. Its use is the same
        as for divars (see above).

m_methodname(method-record) -> word;                         [procedure]
word -> m_methodname(method-record);
        Accesses or updates the word that  is the name part of a  method

m_methodpdr(method-record) -> procedure;                     [procedure]
procedure -> m_methodpdr(method-record);
        Accesses or updates the procedure  that is the method part  of a
        method record.

make_instance(list) -> instance;                             [procedure]
        Makes an instance of the flavour  named by the head of the  list
        by  sending  the  message  "new"  to  the  flavour_of  the  word
        (make_instance  will  try  autoloading  if  necessary).  If  the
        instance will  respond to  the  message "initialise"  (which  is
        defined in  vanilla_flavour) then  the message  "initialise"  is
        sent with the tail of list as argument.

        The method "initialise" defined  in the flavour vanilla  expects
        the list to be of the form:

            [attribute1 value1 attribute2 value2 ... attributeN valueN]

        and will iterate over pairs of items in the list doing

            value -> self <- attribute;

        with each pair or items.

        See also HELP * FLAVOUR_LIBRARY /Protocol for vanilla_flavour

message -> word                                               [variable]
word -> message
        During message sending this is bound to the message being sent.

mixin_flavour -> metaflavour                       [variable -- flavour]
metaflavour -> mixin_flavour
        Metaflavour for  mixins, supplied  with the  system. Mixins  are
        like flavours except that they cannot be instantiated.

myflavour -> metaflavour                            [protected variable]
        During message  sending  time  this variable  is  bound  to  the
        metaflavour of the receiving object.

quitmessage                                           [syntax procedure]
        This is a syntax word  in the same way  as * QUITLOOP is. It  is
        used for jumping out of a message cleanly and can be called from
        within a primary method or a daemon. Any changes already made to
        instance variables will be saved. Any further computation either
        in daemons or primary methods will not be executed. It is a  bit


        but it  is much  safer  as it  ensures  the saving  of  instance

self -> object                                      [protected variable]
        During  message  sending  time  this  is  bound  to  the  object
        receiving the message.

sysflavour(name,                                             [procedure]
    default-values-list) -> flavour_record;
        This procedure which takes nine arguments is responsible for the
        definition  of  (construction  and  alteration)  of  the   class
        structures. It  returns the  flavour record  of the  class.  The
        arguments are:

            a word which is the name of the flavour to be constructed
            or changed.

            a list of components (flavour records) that are the  direct
            superclasses of this flavour. The order is significant with
            the first element having the most precedence.

            a vector  of  names of  lexical  instance variables. It is
            not necessary, but does  not harm, to  include those
            variable that will be inherited from components.

            a vector of names of dynamic instance variables, as above.

            a  list  of  method  records  as  constructed  by
            consmethodrecord to be used as primary methods. See the
            note  on constructing updater methods under
            consmethodrecord above.

            a list  of method  records to  be used  as before daemons.
            As above.

            A list of method records to be used as after daemons. As

            flavour  record of  the  appropriate  metaflavour (usually
            the flavour record of flavour_flavour). If an  existing
            flavour is being  changed this  argument is ignored and can
            be false.

            a  list  of  pairs  associating  instance variables with
            default values. The  pairs should be of the  form
            [value|variable-name]. If  no  default  value  is  provided
            the precedence list is searched for a  value. If none is
            found then undef is the initial value.

        When sysflavour creates a  new flavour it  sends it the  message
        "initialise" (with an empty list as argument) to the flavour  if
        it will  respond  to the  message.  When sysflavour  changes  an
        existing flavour it sends the message "flavour_changed" (with no
        argument) to the flavour if it will respond to the message.

syssendmessage(message, instance);                           [procedure]
value -> syssendmessage(message, instance);
        Sends the  message  message (which  should  be a  word)  to  the
        instance instance. Any arguments required for the processing  of
        the message should be  on the * STACK. The  updater is used  for
        sending an update message. The steps taken in the processing  of
        a message is described below. The class apply of an instance  is
        syssendmessage so the above are equivalent to

            value -> instance(message)

vanilla_flavour -> mixin_flavour                   [variable -- flavour]
mixin_flavour -> vanilla_flavour
        The system root flavour (a mixin). All flavours inherit from it.

ved_lcf                                                    [ved command]
        VED command to Load Current Flavour.

ved_mcf                                                    [ved command]
        VED command to Mark Current Flavour.

6  Some implementation details

When using  the flavour..endflavour  syntax  a method  can refer  to  an
instance variable  by simply  using  its name.  In  some systems  it  is
necessary to tell  the compiler that  you are referring  to an  instance
variable either  by  sending  "self"  a  message  or  by  prefacing  the
reference by a special symbol.

Two kinds of instance variables  are supported by the flavours  system -
dynamic instance variables and lexical instance variables. In the  first
version only dynamic  instance variables were  provided, later  versions
only supported lexical instance  variables which at  the time I  thought
were more efficient. I am no longer so sure.

6.1  Dynamic instance variables
Dynamic instance variables are like normal dynamic variables (*VARS)  in
their scope. They  can be accessed  in methods and  also any  procedures
that a method calls (the procedure need not be a method and need not  be
defined within the scope of the "flavour .. endflavour" syntax form).

When a message is sent to an instance all the dynamic instance variables
associated with its class are set to have the appropriate value for that
instance. After the  message has  been dealt  with the  values of  those
dynamic instance variables are saved as being the value associated  with
the instance. This means that if  a class has 30 dynamic variables  then
there has to be  30 settings before  the message is  run and 30  savings
after the  message  is  run. Every  class  has  a  set-dynamic-variables
procedure and a save-dynamic-variables procedure associated with it.

In fact it is a little more complex since if a method sends a message to
another object  then  the dynamic  instance  variables for  the  current
instance have to be saved before the  message is sent to the object  and
then restored after the message has been sent. For example if we have an
object Andrew and an object Sarah each of which have a dynamic  instance
variable "spouse" associated with it and we have a method marry which is
defined as:

    defmethod marry(person);
        unless person == spouse do  ;;; unless we already married to p
            person -> spouse;       ;;; update the instance variable
            spouse <- marry(self);  ;;; pass on the message

then what we should  be able to  do is send the  message marry with  the
argument Sarah to Andrew. Andrew should  set his value for spouse to  be
Sarah and send the  message on to  Sarah. Sarah will  set her value  for
spouse to be  Andrew and then  pass the  message on to  Andrew. At  this
point Andrew should find that his spouse slot is already filled by Sarah
and so the marrying rally should end. For this to work we are relying on
the fact  that when  andrew gets  the second  marry message  his  actual
internally set value for "spouse" has  been altered. This means that  we
must do a "save" before  the marry method sends  a message to an  object
and a "set" after  the message has  finished. (The only  time it is  not
necessary to do this  additional save and set  is when the object  being
sent the message is the object that is sending it i.e you send a message
to "self").

6.2  Lexical Instance Variables
The scope of lexical instance variables is different from that of POPLOG
*LVARS. A lexical ivar can be accessed  or referred to, by name, in  any
method defined in a flavour which declares (or has previously  declared)
the instance variable,  or has  inherited the  instance variable  from a
component. In  the example  below the  reference to  "a" in  the  method
"printa" will  refer to  the  instance variable  since it  is  inherited
through the flavour b from the flavour a.

    flavour a;
    ivars a;

    flavour b isa a;

    flavour c isa b;
        defmethod printa;
            a =>

References  to  lexical  instance   variables  in  methods  (using   the
defmethod..enddefmethod form) are trapped  and instead of being  planted
as a normal PUSH or POP they are treated as if you had typed:

        ivalof(self, ivarname)

except that the code is slightly more efficient. In fact instead of  one
virtual machine instruction (see REF * VM) (a PUSH, POP, CALL, or UCALL)
seven will  be planted.  This means  that methods  are bulkier  and  the
reference to an instance variable inevitably involves more work.

If you have a method which is only going to refer to a instance variable
once and has many  dynamic instance variables then  you will suffer  the
cost of all the setting and  saving for the instance variables that  are
not referred to. If  the processing of a  message requires referring  to
several instance variables  and you are  going to refer  to most of  the
instance variables then it  is probably better  to use dynamic  instance
variables. I have not  done any investigation into  at what point it  is
more efficient to use one kind of instance variable in place of another.

It is important to note that efficiency is not the only consideration in
choosing the kind  of instance variable.  You may want  the security  of
knowing that if a procedure that a method calls happens to use a dynamic
variable (*VARS) with the same name  as an instance variable then  there
will not be a clash. You may  also want the flexibility of knowing  that
the procedure will access the instance variable.

7  Precedence Ordering

For every  flavour  the  system  keeps  a  list  of  all  the  inherited
components of the flavour  including those implicitly inherited  through
explicit component  specifications.  This  list  is  kept  in  order  of
precedence and no component should occur  twice in the list. The  system
has a default way of constructing  this "precedence list" but users  can
define their  own methods  for doing  so by  including a  method  called
"precedence_list"  in  the  metaflavour  (HELP * METAFLAVOURS   provides
details on how this can be done).

The default  ordering  algorithm  is  that  used  by  LOOPS.  The  basic
principle is that you follow the left most path of the components  (when
a flavour is declared  the order in which  the flavours are declared  is
significant - the first mentioned (left-most) is considered to have  the
highest precedence) until one  of the other paths  joins at which  point
you include the  flavours in  that path  up to  the join.  This is  best
explained by means of  a diagram. Below is  part of an inheritance  tree
for classes of gauge and instrument objects. All the lines represent  an
"isa" or component relationship where the class above "isa" component of
the class below:

            |----------------| |-------------|
    --------|---------       | |          ---|--------------
    |scaled-bar-gauge|  ------ -------    |moving-bar-gauge|
    ------------------  |            |    ------------------
        |  -------------|---  -------|--------  |
        | | horiz-bar-gauge| | vert-bar-gauge | |
        |  -----------------  ----------------  |
        |             |          |---------------
        ----   ------------------|-----
           |   |moving-horiz-bar-gauge|
           |   ------------------------

The precedence list for the scaled-moving-horiz-bar-gauge class would be

    1.  scaled-moving-horiz-bar-gauge - precedence lists include
        themselves first

    2.  scaled-bar-gauge (left most line)

    3.  moving-horiz-bar-gauge (merge at a join)

    4.  horiz-bar-gauge

    5.  moving-bar-gauge

    6.  bar-gauge

    7.  instrument

    8.  ...

Most objects will include  vanilla (the root object)  at the end of  the
precedence list.

7.1  Messages
A message is considered to consist of a selector which should be a  word
and optionally  some (or  none) arguments  which might  be any  kind  of
object. The selector  is used  to determine  how the  message should  be
received, in most cases a procedure (a method) is applied. The arguments
are left on the stack for the method to deal with as appropriate.

The procedure syssendmessage first checks the protected variable  "self"
to see if the message sender is an instance. If it is then the  instance
is "saved" (its  store for  its dynamic instance  variables are  updated
from the  value of  the  variables). Then  normal message  reception  is

7.2  Message Reception
The dynamic instance variables of the message receiver are set. Then any
before daemons called  "any_message" found  in the  precedence list  are
fired in the order in which they are found in the precedence list.  Then
all before daemons appropriate to the message are fired (iff there  is a
primary method for the message or the message is the name of an instance
variable), they  are fired  in the  order of  the precedence  list -  by
default most specific first - then one, and only one, primary method  is
selected from the precedence list -- or an instance variable is accessed
(updated if the message is sent in update mode). Then the after  daemons
are executed in  the reverse order  of the before  daemons. Finally  all
after daemons called "any_message" are fired in the reverse order of the
precedence list  and  the  dynamic instance  variables  of  the  message
receiver  are  saved  and  then  if  the  message-sender  is  an  object
(syssendmessage found that self was an instance when it began) then  its
dynamic instance-variables are reset.

Currently it  is  not easy  to  change the  way  in which  messages  are
received. You  can  alter they  way  in  which the  precedence  list  is
constructed but you  cannot for example  stop the firing  of daemons  or
allow more than one primary method to be activated.

A distinction is  made between messages  sent in normal  mode and  those
sent in * UPDATER mode. In update mode the primary method must have been
declared as  an  updater  (unless  the message  refers  to  an  instance
variable) and  only  daemons  defined as  updaters,  using  the  keyword
"updaterof", are fired. This applies  to both "any_message" daemons  and
those specific to particular messages.

7.3  Method Selection
When a message is sent a method has  to be found to respond to it.  This
task involves looking at each of  the components in the precedence  list
to see if there is a method with the appropriate name. If none is  found
all the instance variable names are checked to see if any of their names
match the message. If  no method can be  found and no instance  variable
matches then the system tries to send the message "default_method"  with
the original method  as argument.  If no default_method  can be  found a
mishap occurs. (The flavour vanilla provides a default method which will
try and autoload a file called '<message>_message.p' and if it  succeeds
re-sends the original message  to itself. If it  cannot autoload a  file
successfully then it will call mishap).

In order to speed up the  time spent in choosing the appropriate  method
the FLAVOURS uses  a 'caching' facility.  At flavour  definition/compile
time it is  possible to know  all the possible  messages an instance  of
that flavour can respond to and  what methods and daemons will be  fired
for each of the messages. This means that it is possible to  construct a
procedure for each of  the classes that will  handle a message  destined
for an instance of that class. The procedure might be defined as:

    define run_message_for_person(instance, message);
        if message == "marry" then
            /* before daemons, primary method, after daemons */
        elseif message == "birthday" then
            /* before daemons, primary method, after daemons */
        elseif message == "age" then
            /* before daemons, instance-variable value, after daemons */
            /* default_method daemons and primary method */
    define updaterof run_message_for_person(instance, message);

NOTE: At some later date it may  be feasible to change the way in  which
these class specific procedures are defined to do something like jump on
the basis of the first character of the method in order to ensure a more
even and perhaps faster method selection.

7.4  Delayed Compilation
The only problem with  using this kind of  caching is that every  time a
flavour is  changed not  only its  class specific  procedure has  to  be
rebuilt but also the procedures of all the classes inherit from it. This
could make the package very slow and bulky. For this reason the flavours
system notes that the  procedure of a class  needs to be  reconstructed,
but does not  actually construct it  until it is  required -- the  first
time a message  is sent to  one of  its instances. This  means that  the
first time a message is  sent to an instance of  a class which has  been
redefined, or one of its components has been redefined, the reception of
the message will take slightly longer than for subsequent messages sent.

Since most object oriented programmes include several 'mixin' classes --
classes which serve  as a place  holder in the  inheritance lattice  but
which are not going to  be instantiated this delayed compilation  serves
to limit the amount of extra work that is done and space that is used.

8  Bugs and Omissions

The flavours  package  could  be  enhanced by  the  provision  of  class
variables, a syntax for sending a message iff it is handled and a method
by which users can easily specify how a message should be handled.

--- C.all/ref/flavours
--- Copyright University of Sussex 1990. All rights reserved.