Go to the first, previous, next, last section, table of contents.

Comparison with other object models

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.