A lightweight, portable, object-oriented component framework
Dick Pountain
Oberon/F is the latest addition to an important new software category, the object-oriented component framework. NextStep's AppKit is the most famous current exemplar; Taligent's TalAE will soon be contesting that title. Oberon/F provides a thin object-services layer that runs on top of the host operating system and lets you write cross-platform, portable, and extensible applications as if the host operating system supported full object orientation. Although currently in beta for Windows and Macintosh System 7, Oberon/F versions are also planned for OS/2 and Unix/Motif. The Oberon/F system is being developed by Niklaus Wirth's Oberon Microsystems (Zurich, Switzerland).
Component frameworks aim to reduce the huge learning curve of class libraries and to enable software reuse by supplying big and already-useful chunks. If using a class library is like buying a load of bricks, then using a framework is like erecting a prefabricated house, with the walls already assembled.
Oberon/F is a wholly document-centric framework in which everything is a document that you can edit within the development system, which also serves as the run-time system. Every Oberon/F document contains one or more views--software components that let you view and edit a particular data type, such as text, a graphic, or a spreadsheet. Each view is implemented by a separate module, which gets dynamically linked and loaded on demand like a DLL. Unlike with Windows DLLs or VBXes (Visual Basic custom controls), however, you can extend Oberon/F modules. If the appropriate module is present, any Oberon/F document editor can edit any type of view, so the concept of applications owning files completely d
issolves.
Oberon/F incorporates a highly efficient but proprietary compound document model that lets you embed views into one another in arbitrarily complex ways. In future releases, this system will be progressively integrated with OLE and OpenDoc.
The Oberon/F Development Environment
Oberon/F is based on Oberon 2, language successor to Pascal and Modula 2, and includes a compiler and debugger for this language. Oberon 2 is a strongly typed, compiled language that supports both modular and object-oriented programming as well as Eiffel-like precondition and postcondition testing using ASSERT statements. It includes an automatic garbage collector to preserve memory integrity, an unusual feature for a compiled language. The driving force throughout the Oberon/F project has been the pursuit of simplicity. The beta-0.9 Oberon/F system arrived on a single 1.44-MB floppy disk and occupies barely 4 MB of hard disk space.
The programming, editing, and debugging environment
is completely integrated, giving it the same feel as interactive interpreted systems like SmallTalk or Lisp. This is an illusion, as Oberon 2 compiles straight to 32-bit native 486 or 680x0 code. However, the compiler is so fast at 15,000 lines per minute, and the modules you write are typically so small, that compilation time is seldom noticeable.
The compiler, debugger, and other software tools are all based on Oberon/F compound documents. In a Show Loaded Modules window, for example, you can highlight any module name in the list and immediately decompile its interface definition; in a debug window, clicking on diamond-shaped markers lets you follow pointers and traverse lists; in the editor, errors are flagged by markers embedded in the text, which expand into error messages when you click on them.
The Texts Subsystem
The first release of Oberon/F provides just two component subsystems called Texts and Forms. But an ODBC (Open Database Connectivity) database subsystem
is planned for the second release, and Oberon Microsystems says that several U.S. and European consulting firms plan to develop and market additional components. In-place editing of industry-standard graphics and spreadsheet formats won't be available until a later release supports OLE 2.
The Texts subsystem is a word processor with features that are roughly equivalent to Windows Write--it supports fonts, paragraph attributes, and object embedding. Unlike with Write, however, you can extend this editor in any way you like. As a test example, I decided to add the ability to change a selected passage of text into uppercase (see the code in the listing "
Extending the Oberon/F Texts Component
"). A rather minor achievement, you might think, but consider these points:
1. This is not just a WordBasic-style macro but rather a native 486
code extension to the system.
2. This new ability is available within any piece of text in Oberon/F
and will continue to be available in a
ny future programs that I add.
3. I did not need to recompile the text editor and, indeed, have never even
seen its source code, only the published programming interface.
4. This same code works identically on a Windows PC or on a Mac and
automatically displays the proper "look and feel" of either platform.
In Oberon/F, exported parameterless procedures are called commands, and they are executable from anywhere in the system. The procedure UpCase* (the asterisk indicates that it's to be exported by the module DickText) is a command that performs its action on the selection of the window that currently has the focus.
You can program Oberon/F at three levels of complexity, and my example illustrates the simplest command programming that adds new functions to an existing view. The next higher level is the writing of new views, which are visual representations for data types. The third, and hardest level, is the writing of container views that can contain other embedded views. O
beron/F editors are normally container views.
The Forms Component
The Forms component is a simple visual design tool for data-entry forms and dialog boxes. First, you write a code module that defines a record data type with various fields, and then you design the corresponding form by visually dragging control objects around on it as you would in Visual Basic. Thereafter, the Oberon/F run-time system creates and maintains the connections between the screen fields and the underlying data structure without your having to write any further code, automatically updating the field variables whenever you enter data into the form. The reverse process is not automatic, so when your program updates a record field, it must broadcast an update message telling all screen views that they need to change, too.
Oberon/F forms are stored as documents. You can modify their appearance without forcing a recompilation of the application code, a great advantage compared with conventional code g
enerators. You can embed forms in texts and vice versa, recursively to any depth, to construct a variety of user-interface styles.
Models, Views, and Controllers
Oberon/F is designed around a hierarchy of abstractions that isolate modules from the physical hardware (for cross-platform portability) and from one another (for extensibility). The physical display, printing, and file systems are hidden in abstract object classes and are accessed by creating reader and writer objects for them.
The most fundamental data type is a Store, which represents a body of persistent data that knows how to save and retrieve itself from a nonvolatile medium like a hard disk. The module Stores supplies readers and writers that can map Oberon 2 data types--such as characters, integers, sets, and other stores--into binary data. Stores can contain other embedded stores and, hence, can represent compound documents. Store is an abstract type that is never instantiated directly; instead, Oberon/F
supplies three extensions of Store called Models, Views, and Controllers. This MVC (Model-View-Controller) paradigm was originally devised by the SmallTalk team at Xerox PARC.
Crudely put, the model is the data, whereas a view is a particular presentation of the data transformed into a rectangular display area. There may be many views onto the same model, and if the model is changed, this fact must be broadcast to all the views by sending messages. A view might directly handle interaction with a user's mouse and keyboard, but in complex applications, this task is usually delegated to a Controller object. Models, Views, and Controllers are extensible. In the listing, you'll see the use of a TextController object c to measure the current text selection, but the actual processing takes place on a TextModel called buf.
Safety First
Although Oberon/F makes great use of inheritance internally (e.g., Stores -> Models -> TextModels), it strictly controls external inheritance to
preserve extensibility by imposing the classic separation of interface from implementation. Many modules deliberately don't export concrete types used in their interface, which prevents application programmers from extending them directly. Instead, they let you merely create instances of a hidden concrete type, together with an abstract interface type that you can inherit to reimplement extensions of the type. This mechanism retains most--though not all--of the power of inheritance, but it's necessary to guarantee the future extensibility of the program's semantics without running into the so-called fragile base-class problem (see "Extensible Software Systems," May 1994 BYTE).
In the messy world of PC operating systems, Oberon/F's simplicity and austerity could hardly be more at odds with industry practice. C++ programmers like to party and then use industrial-strength debugging tools, like BoundsChecker and Pu-rify, to clean up the mess afterwards. The Oberon 2 programmer expects to catch 90 percent o
f the errors at compile time and most of the remainder by careful choice of preconditions. Of course, adapting to changing requirements is the ultimate software challenge, and that's where Oberon/F shines. "If the paradigm of object orientation is promising," says Wirth, "this is mostly because object-oriented programming allows us to design genuinely extensible modular systems."
ABOUT THE PRODUCT
Oberon/FCommercial version......$350
Educational version.............free
Oberon Microsystems, Inc.
Solothurnerstrasse 45
CH-4053 Basel, Switzerland
+41 (0)61 361 3858
fax: +41 (0)61 361 3846
E-mail: oberon@applelink.apple.com
Ftp: hades.ethz.ch
MODULE DickText;
IMPORT TextModels, TextControllers;
PROCEDURE UpCase*;
VAR beg, end: LONGINT;
ch: CHAR;
c: TextControllers.Controller;
buf: TextModels
.Model;
r: TextModels.Reader;
w: TextModels.Writer;
BEGIN
(* determine extent of selected text *)
c := TextControllers.Focus();
IF (c ## NIL) & c.HasSelection() THEN
c.GetSelection(beg,end);
(* make a buffer for uppercase text *)
buf := TextModels.dir.New(); (* a directory object *)
w := buf.NewWriter(NIL);
r := c.text.NewReader(NIL);
r.SetPos(beg);
(* process selected text into buffer *)
r.ReadChar(ch);
WHILE (r.Pos()
IF (ch >= "a") & (ch
<
= "z")
THEN ch := CAP(ch) END;
w.WriteChar(ch);
r.ReadChar(ch)
END;
(* copy buffer back into document *)
c.text.Delete(beg,end);
c.text.CopyFrom(beg,buf,0,end-beg);
END
END UpCase;
END DickText.
Dick Pountain is a BYTE contributing editor based in London. You can reach him on the Internet or BIX at
dickp@bix.con
.
The Oberon/F System
