---

6.25.7 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). This section discusses the relation of the object models described here to two well-known and two closely-related (by the use of method maps) models. Andras Zsoter helped us with this section.

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) but this model has a number of limitations ³⁶:

• It uses a selector object syntax, which makes it unnatural to pass objects on the stack.
• It requires that the selector parses the input stream (at compile time); this leads to reduced extensibility and to bugs that are hard to find.
• It allows using every selector on every object; this eliminates the need for interfaces, but makes it harder to create efficient implementations.

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 18(1) 1996, pages 31-35) 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 Zsoter’s model, because the receiving object is the active object already. On the other hand, the explicit change is absolutely necessary in that model, because otherwise no one could ever change the active object. An Standard Forth implementation of this model is available through http://www.forth.org/oopf.html.

The oof.fs model combines information hiding and overloading resolution (by keeping names in various word lists) 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.fs model is quite similar to a very stripped-down version of the objects.fs model, but syntactically it is a mixture of the objects.fs and oof.fs models.