felix <felixundduni@freenet.de> wrote:
+---------------
| >> [CL] "adjustable arrays", and the links to MAKE-ARRAY and ADJUST-ARRAY.
| >
| >Quite right. Ironically, so does Smalltalk,[...]
|
| Smalltalk has `become:', which is orders of magnitude more powerful
| and general than fill-pointers...
+---------------
Indeed. Similarly, Common Lisp provides dynamic redefinition of
classes, wherein all existing instances of the class get automatically
converted to the new class definition (which can be customized
with UPDATE-INSTANCE-FOR-REDEFINED-CLASS), as well as CHANGE-CLASS
(dynamically change the class of a specific instance, which can
be customized with UPDATE-INSTANCE-FOR-DIFFERENT-CLASS).
These changes can cause slots to be added or deleted, or be completely
redefined while the program is running. E.g., there's an example at
<URL:http://www.xanalys.com/software_tools/reference/HyperSpec/Body/
f_upda_1.htm> of defining a class "X-Y-POSITION" in rectangular
coordinates, running the program for a while (instantiating a number
of instances), then noticing that:
;;; It turns out polar coordinates are used more than Cartesian
;;; coordinates, so the representation is altered and some new
;;; accessor methods are added.
By defining a method for UPDATE-INSTANCE-FOR-REDEFINED-CLASS which
is specialized for class X-Y-POSITION before the redefinition, the
existing instances can be automatically converted from rectangular
coordinates to polar.
Two points (pardon the pun!) that may be of interest from "4.3.6
Redefining Classes" <URL:http://www.xanalys.com/software_tools/
reference/HyperSpec/Body/04_cf.htm>:
When the class C is redefined, changes are propagated to its
instances and to instances of any of its subclasses. Updating
such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is
read or written.
That is, the implementation is permitted to call UPDATE-INSTANCE-FOR-
REDEFINED-CLASS on instances lazily, as needed, thus spreading out
the computational load of the conversion (or deferring it altogether
for instances that are never accessed after the redefinition). And:
Updating an instance does not change its identity as defined by
the function EQ. The updating process may change the slots of
that particular instance, but it does not create a new instance.
This almost (but not quite) mandates a level of indirection between
an "instance" and the internal storage for the instance. [I say "not
quite" because that indirection need not occur for classes which are
never redefined... though I don't know if any existing implementations
actually make use of that flexibility.]
-Rob
-----
Rob Warnock, 30-3-510 <rpw3@sgi.com>
SGI Network Engineering <http://www.rpw3.org/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]