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
REF * METAFLAVOUR_FLAVOUR.
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
exported.
2.2 SYSFLAVOUR
---------------
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
HELP * DEFAULT_METHOD)
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
define..enddefine.
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.
Examples:
1. A simple method:
defmethod birthday;
age + 1 -> age;
enddefmethod;
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;
enddefmethod
3. A complex method definition:
defmethod before updaterof location;
location <- player_leaves(self)
enddefmethod
See TEACH * FLAVOURS for full details of the flavour package,
including details of usage. See also HELP * DEFAULT_METHOD,
REF * 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
variables.
For example:
flavour person novanilla;
ivars name age sex;
defmethod birthday;
age + 1 -> age;
[happy birthday to ^name] =>
enddefmethod;
defmethod printself;
pr('an object called '); pr(name);
enddefmethod;
endflavour;
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] =>
enddefmethod;
defmethod crawl:
[^subject is fascinating] =>
enddefmethod;
endflavour;
See TEACH * FLAVOURS, and REF * DEFMETHOD,
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
variable.
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
record.
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
like:
exitfrom(syssendmessage)
but it is much safer as it ensures the saving of instance
variables.
self -> object [protected variable]
During message sending time this is bound to the object
receiving the message.
sysflavour(name, [procedure]
component-list,
lexical-ivar-vector,
dynamic-ivar-vector,
method-list,
before-daemon-list,
after-daemon-list,
metaflavour,
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:
name
a word which is the name of the flavour to be constructed
or changed.
component-list
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.
lexical-ivar-vector
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.
dynamic-ivar-vector
a vector of names of dynamic instance variables, as above.
method-list
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.
before-daemon-list
a list of method records to be used as before daemons.
As above.
after-daemon-list
A list of method records to be used as after daemons. As
above.
metaflavour
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.
default-values-pair
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
instance(message)
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
endunless;
enddefmethod;
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;
endflavour
flavour b isa a;
endflavour;
flavour c isa b;
defmethod printa;
a =>
enddefmethod;
endflavour;
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:
|
------------
|instrument|
------------
-----------
|bar-gauge|
-----------
|----------------| |-------------|
--------|--------- | | ---|--------------
|scaled-bar-gauge| ------ ------- |moving-bar-gauge|
------------------ | | ------------------
| -------------|--- -------|-------- |
| | horiz-bar-gauge| | vert-bar-gauge | |
| ----------------- ---------------- |
| | |---------------
---- ------------------|-----
| |moving-horiz-bar-gauge|
| ------------------------
-------------------------------
|scaled-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
begun.
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
.
.
elseif message == "age" then
/* before daemons, instance-variable value, after daemons */
elseif
.
.
else
/* default_method daemons and primary method */
endif;
enddefine;
define updaterof run_message_for_person(instance, message);
.
.
enddefine;
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.