[comp.object] Please critique this OO language design

thinman@cup.portal.com (Lance C Norskog) (03/03/91)

The following is my attempt at a graphics programming language.
This is not really an object-oriented programming language, but is
instead an object-oriented simulation system.  You describe a
3D scene with spheres, polyhedra, etc. and the responses of
these items to user input.

I originally designed it as a primitive functional programming
language, but then I finally got around to learning OO and realized
that it should be OO.  I'm a fanatic about zen simplicity, and 
switching to OO got rid of various annoying features, like types.

I took a whack at C++ and decided that it's a hopeless mess.
I've started learning Smalltalk, and since I don't know any better
the OO model I'm using is Smalltalk-flavored.  I.e. it's tree-shaped
with single inheritance.

The jargon flies thick here on comp.object, but I generally understand
it.  I'd appreciate it if you OO experts would take a look at it and
tell me whether I'm at least on the right track, or point me at the
right OO model for this application.

--------------------------------------------

5D is a scene specification language for 3D real-time
graphics.  It is the basis of a 3D real-time networked
window system.  It can present static graphics scenes for
examination, and can implement the real-time graphics
interface for application programs running on other
machines.  5D contains network interaction commands, and
communicates with applications and other 5D viewers.  5D is
intended as a powerful base language for multimedia, Virtual
Reality, & Cyberspace applications.  Its also intended as a
base for building a desktop computing environment such as
Xerox Parc's Information Visualizer (Byte Magazine, February
1991).

The fundamental paradigm is object-oriented expressive
programming: a lattice, or directed acyclic graph, of
arithmetic operations feeds a set of graphics primitives
with numerical information.  The lattice is a dataflow
network which supplies position, speed, and other
information to spheres, cubes, etc.  Every screen redraw
(perhaps 1/10 of a second) the lattice is completely
traversed and graphics objects are drawn at their new
position.  This is the basic concept of the system; there
are extensions for sound I/O, network communication, and
various input devices.

As a scene specification language, it does not have
procedural programming constructs.  The programmer does not
say, "do this, do that, maybe do the other".  Instead, the
language contains descriptions of things.  A sound channel
simply exists, has a quality to it, and a volume parameter.
The arithmetic lattice may supply the volume parameter with
a value derived from the sound's distance from the user in
the 3D scene.

For the rest of this discussion, for simplicity we will just
talk about the screen update phase.

During the screen refresh cycle described above, the
language may not contain constructs which require an
unpredictable amount of time.  Thus, very high-level
language concepts like actors, object messaging, dynamic
instantiation, etc. can not be used.  The lattice is limited
to formulae with bounded execution time.  During program
start-up, the 5D system reads in the scene description,
processes the language into the arithmetic lattice which
feeds the screen, and starts running the screen.

5D uses trees and inheritance. All items in the scene are
arranged in a tree.  Nodes of the tree may be visual
objects, sound channels, or communication endpoints, and the
subtrees of these nodes are arithetic function trees.  Some
items possess attributes called "properties" which are
inherited from above and may be changed at each level.  The
changed properties are inherited by children of the changer.

5D is object-oriented. Objects are macro definitions for the
contents of the arithmetic lattice.  The lattice is derived
from object descriptions in a preprocessing phase. The
object system is tree-shaped. A class derives from a parent
class, and may add new operators or override operator
definitions of the parent class.

The core object set consists of those language elements
which must be implemented by built-in software.  The main
object, Object, has object-ness but nothing else; in short,
it is just there.  The Number object subclasses off of
Object, and contains a real number.  It also contains a set
of "templates":  arithmetic addition is defined by the tree
template

        template Number plus(Number, Number)

which merely says that the value of the plus operator on two
Numbers is a Number.  Thus,

        plus(Number, plus(Number, Number))

is covered by two applications of the above template.  The
Point object contains the template

        template Point multiply(Number, Point)

which, of course, multiplies a scalar by a vector to get a
vector.

The templates provide definitions of what operators an
object implements; in programmer-defined objects they are
accompanied by function trees referencing other objects.
For example, an abridged object definition for complex
numbers:

        define object Complex
        superclass Object
        public Number real, imag
        template Complex plus(Complex, Complex)
                assign(real, plus(input1.real, input2.real))
                assign(imag, plus(input1.imag, input2.imag))
        template Complex assign(Complex, Complex)
                assign(input1.real, input2.real)
                assign(input1.imag, input2.imag)

The Complex object contains two numbers, and implements
complex arithmetic.  Complex subclasses from Object instead
of Number because since it is two numbers, the rules for one
number can't apply to it.  (The assign statements use the
Pascal-ish method of returning values.)  The 5D system
generates an arithmetic tree of core objects working from
the template patterns in user-defined objects in an
iterative rewrite algorithm.  Thus,

        Complex C1, C2, C3
        assign(C3, plus(C1, C2))

generates the arithmetic expressions

        assign(C3.real, plus(C1.real, C2.real))
        assign(C3.imag, plus(C1.imag, C2.imag))

The intermediate plus(C1, C2) node conceptually exists as a
Complex object momentarily for the purposes of the rewriting
phase.

The template facility is a powerful context-sensitive device
for describing the use of an object.  A template may refer
to an invocation of itself in the middle of a tree and
replace the whole tree with a new function.

The above classes only implement arithmetic operations.  The
Drawable class possesses visual properties such as color and
position.  The position property is a Point.  The color
property is a Point in RGB color space.  A property may be
an object, or a arithmetic tree of objects, if those objects
have no properties.  The Triangle is a built-in object
subclassed off of Drawable.  It consists of three Points.
Each Point is, course, three Numbers.  Thus a Triangle may
have nine arithmetic trees underneath it, and constantly
change shape as those subtrees change value.  A 3D modelling
program might use this to rubber-band changes in a 3D shape
in response to numerical input devices.