Previous: Mini-OOF2, Up: Object-oriented Forth   [Contents][Index]

---

6.27.7 Comparison of 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).

A number of Forth object-oriented models were inspired by Neon (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. By contrast, all models discussed in this manual have objects on the stack, leading to a object selector syntax.
• 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. In oof.fs there is also parsing of the input stream, in the other models this does not happen for regular selector invocations.
• It allows using every selector on every object; this eliminates the need for interfaces, but makes it harder to create efficient implementations. The models included with Gforth typically only support using selectors on objects of certain classes, with surprising and usually unpleasant results if you use a selector on other objects (or other things).

Another difference between object models is whether they have an active object such as this in objects.fs. mini-oof.fs does not have an active object, and uses the top-of-stack as the object for instance variables and the selector.

And if they have an active object, there are differences in what sets or changes it, and what make use of the active object.

• In objects.fs this is only changed on method invocation (i.e., by m: ... ;m; note the possible separation between methods and selectors in objects.fs), and restored when leaving the method. Only instance variables use this, while selectors take their object from the stack.
• In mini-oof2.fs only >o ... o> changes the active object, and both selectors and instance variables use the active object as the object for which the selector is invoked, or the instance variable accessed. However, mini-oof2.fs has a recognizer that recognizes .word and executes/compiles/postpones code equivalent to >o word >o, so you can use it like objects.fs by always invoking selectors with a prefixed ‘.’, and never invoke instance variables in that way.
• In oof.fs selector/method invocation changes the active object, like in object.fs, but it also has >o ... o> like mini-oof2.fs (but without a helping recognizer).

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 (like in mini-oof2.fs; you have to change the active object explicitly with { ... } (similar to how you use >o ... o> in oof.fs and mini-oof2.fs). A 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).