\chapter{\productpl{} architecture} \label{sec:globalarch}

In this appendix we present an overview of \product{}'s primitives
and the interaction to the \productpl{} environment.


\section{What is ``Object-Oriented''?}

\product{} is an object-oriented system. This implies that the basic
entity in \product{}'s world is an object, an entity with state capable
of performing actions. Such an action is activated by sending the object
a {\em message}.

So far, most object oriented systems agree.  Starting from these
notions however one can find object oriented environments that take
widely different approaches for representing objects, actions on
objects and sending messages.

Rather than specifying operations on each individual object most OO
environments define some way of sharing the operation definitions
(called {\em methods}). There are two ways to share methods. One is to
create objects as a copy of other objects and then modify them (by
attaching and deleting slots and methods) to fit the particular need. If
a series of similar objects is needed, one first creates an object that
satisfies the common functionality and then creates multiple copies of
this object. This approach is followed by SELF
\ifpw{(Chambers)}{\cite{chambers:89}}. The other ---more traditional---
approach is to define a {\em class}. A class is an entity in the object
oriented environment that defines the constituents of the persistent
state and the methods for each of its {\em instantiations}.

\product{} takes the latter approach, but adds some notions of the
object-copying approach because GUI's often contain unique objects and
because object modification is more dynamic and therefore more suitable
for rapid prototyping.


\section{\product{}'s objects}

More concretely, a \product{} object is a set of {\em values} of {\em
instance variables} bundled into a single entity which is referred to by
its {\em object reference}. An object is an instantiation of a {\em
class}. A class holds the key to decoding the information of its
instances:% 
    \footnote{We will mix the terms {\em instance} and {\em object}
              freely in this document.  They are considered synonyms.}
the instance variables.  The class also serves as a placeholder
for storing the methods understood by its instances.  \Figref{arch1}
illustrates this.

\postscriptfig[width=4in]{arch1}{Classes and Objects in \product{}}


\subsection{Classes}

As explained above, a \product{} class describes the storage-layout and the
methods of its instances.  In \product{} a class is a normal object.  It is
an instance of class {\em class}.%
    \footnote{Class class is an instance of itself.  In other systems
	      (SmallTalk, \ifpw{}{\cite{Goldberg:83a}}), classes
	      are instances of a {\em meta-class}. Yet in other systems,
	      classes have a completely different status (for example
	      widgets in the X11 Intrinsics)}
\index{inheritance,of classes}%
As in most OO systems \product{} classes may inherit from a {\em
super-class}.  \product{} classes are organised in a single-inheritance
hierarchy.%
    \footnote{Multiple inheritance introduces various technical and
	      conceptual problems.  \product{} uses delegation and
	      templates to achieve similar results.  This is
	      explained in \secref{delegation} and
	      \secref{template}.}
The root of this hierarchy is class {\em object}.  Class object is the
only class without a super-class.  \Figref{pceclasshierarchy} gives
the complete hierarchy of \product{} built-in classes.

\postscriptfig[height=8in]{pceclasshierarchy}{\product{}'s Class hierarchy}


\section{Objects and integers}

Except for integers, everything accessible to the user is represented
as an object.  By implementing classes, instance variables, methods,
messages, conditions, constants, variables, etc.\ as objects
everything in \product{} may be accessed through the basic predicates
new/2, send/[2-12] and get/[3-13] from Prolog.


\section{Delegation}		\label{sec:delegation}

\index{delegation}\index{multiple inheritance}\index{inheritance,multiple}
\product{} does not offer multiple inheritance.  Sharing functionality from
multiple classes is generally dealt with using {\em delegation}.
Delegation implies that messages not understood by a principal object
are forwarded to an object that is associated to it.

For example, \product{} defines class \class{editor} to be a graphical object
capable of editing text.  Most applications require a \class {window}
capable of editing text.  This is implemented by \product{}'s class
\class{view}, which is not a subclass of both editor and window, but
just of window.  The window displays an instance of class \class{editor}
and constrains the size of the editor to occupy the entire visible area
of the window.  Any message arriving on the view that is not defined on
class \class{view} (or class \class{window}) will be forwarded to the
associated editor object.

The dynamic nature of delegation makes this mechanism more flexible
than multiple inheritance.  For example, \product{} defines class \class{node}.
This class defines the communication to a \class{tree} to automate the
layout of hierarchies.  A node can manipulate any graphical object.
Using multiple inheritance would require a class {\em box_node},
{\em circle_node}, etc.


\section{Prolog}

As we have seen in \secref{starting}, activating \product{} is done by
providing the user with access to \product{}'s message passing primitives.
Near the end of \secref{starting} we briefly explained how
control is passed from \product{} to Prolog.  The predefined object @prolog is
(the only) instance of class {\em host}.  Any message sent to this
instance will be mapped on a Prolog goal and given to the Prolog system
as a query: the {\em selector} of the method will be used as a predicate
name.  The arguments will be translated from \product{} data-types to their
corresponding Prolog data-types according to the transformation rules
described in \secref{interface}.  

The relation between \product{} and Prolog is described in detail in
\chapref{pceprolog}.  Examples can be found throughout this manual.

\Figref{control} shows the data- and control-flow between
\product{} and Prolog.  The lines with arrows indicate data-flow in the
direction of the arrow.  The dotted ellipse with arrows indicates
the flow of control.

\postscriptfig[width=\textwidth]{control}{Data and Control flow in \productpl{}}

\section{Executable objects}

Executable code (statements, control-structures, variables, etc.) can be
expressed as first-class objects.  Such expressions can be associated
with controls to specify their actions, to method objects to specify
their implementation and as arguments to method invocation to specify
details of the operation to be performed.

Executable objects are used in many of the examples in this manual.
\Secref{exeobjects} provides an overview of them.


\section{Summary}

This section explained the basic object-oriented notions used in
\product{}.  \product{}'s data is organised in {\em objects} and integers.  An
object represents a state.  An object is an instance of a class.
A class describes the constituents of the state represented in
its instances and the methods (actions) understood by its instances.

A class is a normal object, as are all the other constituents of \product{}'s
programming world: methods, instance variables, messages, expressions,
etc.  This uniform representation allows for inspecting and changing \product{}
using the four basic interface predicates from Prolog.

The basic interface predicates pass control from Prolog to \product{}.
As control is to be passed from \product{} to Prolog (for example if
the user presses a button), a message is send to @prolog, the
only instance of class host.  This object will create a goal
from the message and pass this goal to the Prolog environment.