Many object-oriented Forth extensions have been proposed (A survey of object-oriented Forths (SIGPLAN Notices, April 1996) by Bradford J. Rodriguez and W. F. S. Poehlman lists 17). Here I'll discuss the relation of `objects.fs' to two well-known and two closely-related (by the use of method maps) models.
The most popular model currently seems to be the Neon model (see
Object-oriented programming in ANS Forth (Forth Dimensions, March
1997) by Andrew McKewan). The Neon model uses a selector
object
syntax, which makes it unnatural to pass objects on the
stack. It also requires that the selector parses the input stream (at
compile time); this leads to reduced extensibility and to bugs that are
hard to find. Finally, it allows using every selector to every object;
this eliminates the need for classes, but makes it harder to create
efficient implementations. A longer version of this critique can be
found in On Standardizing Object-Oriented Forth Extensions (Forth
Dimensions, May 1997) by Anton Ertl.
Another well-known publication is Object-Oriented Forth (Academic Press, London, 1987) by Dick Pountain. However, it is not really about object-oriented programming, because it hardly deals with late binding. Instead, it focuses on features like information hiding and overloading that are characteristic of modular languages like Ada (83).
In Does late binding have to be slow? (Forth Dimensions ??? 1996)
Andras Zsoter describes a model that makes heavy use of an active object
(like this
in `objects.fs'): The active object is not only
used for accessing all fields, but also specifies the receiving object
of every selector invocation; you have to change the active object
explicitly with { ... }
, whereas in `objects.fs' it
changes more or less implicitly at m: ... ;m
. Such a change at
the method entry point is unnecessary with the Zsoter's model, because
the receiving object is the active object already; OTOH, the explicit
change is absolutely necessary in that model, because otherwise no one
could ever change the active object. An ANS Forth implementation of this
model is available at http://www.forth.org/fig/oopf.html.
The `oof.fs' model combines information hiding and overloading
resolution (by keeping names in various wordlists) with object-oriented
programming. It sets the active object implicitly on method entry, but
also allows explicit changing (with >o...o>
or with
with...endwith
). It uses parsing and state-smart objects and
classes for resolving overloading and for early binding: the object or
class parses the selector and determines the method from this. If the
selector is not parsed by an object or class, it performs a call to the
selector for the active object (late binding), like Zsoter's model.
Fields are always accessed through the active object. The big
disadvantage of this model is the parsing and the state-smartness, which
reduces extensibility and increases the opportunities for subtle bugs;
essentially, you are only safe if you never tick or postpone
an
object or class (Bernd disagrees, but I (Anton) am not convinced).
The Mini-OOF model is quite similar to a very stripped-down version of the Objects model, but syntactically it is a mixture of the Objects and the OOF model.
Go to the first, previous, next, last section, table of contents.