ECLiPSe supports object-orientation through two distinct features, modules and structures. Modules support behavioural object orientation, and structures support structural object orientation.
Because of the nature of combinatorial problems, the only requirement for behavioural object orientation is in the constraint handlers. The implementation of each constraints library is hidden inside a module, and access to the internal data structures is only through predicates exported from the module.
The remaining objects that can occur in an ECLiPSe model have attributes but no behaviour, and so they require only structural object orientation.
In our first example we modelled a map colouring problem using only variables and constraints. It can be argued, however, that for more complex applications, the conceptual model can benefit from a notion of object, into which variables can be built. For example in modelling a resource scheduling problem the notion of a task with certain attributes is useful. A task might have an identifier, a start time, and end time and a duration.
After declaring structures for tasks and times, as below, the programmer can access any of their attributes independently.
[eclipse 1]: lib(structures).
* structures loaded
[eclipse 2]: define_struct( task(id, start, end, duration)),
define_struct( time(hour, minute)).
* yes.
[eclipse 3]: T=task with [id:a,duration:10].
* T = task(a, _, _, 10)
* yes.
[eclipse 4]: T1=task with [id:a3,start:S3,end:(time with hour:H3)],
T2=task with [id:a4,start:S3,end:(time with hour:H4)],
H3>H4.
* T1 = task(a3, S3, time(H3, _), _)
* T2 = task(a4, S3, time(H4, _), _)
* yes.
Defining a Task Structure
Each ECLiPSe prompt (eg [eclipse 1]:) is followed by a user query
(eg lib(structures).).
In the rest of the article, ``query N'' always refers to the query
which is preceded
by the prompt [eclipse N]:.
The programmer enters lib(structures). to which the system
responds structures loaded.
I have added a star to the beginning of each line showing a system
response.
Query 2 defines the attributes for objects in the classes task and
time.
Query 3 shows how the user can equate a variable with a structured
object (i.e. the variable is instantiated to the structure).
ECLiPSe automatically constructs unknown values (written _) for the
unspecified attributes.
Query 4 illustrates something of the expressive power needed in a constraint programming language which supports objects. Not only do the objects T1 and T2 share an attribute value - this is a shared subobject - but they also have non-shared subobjects whose attributes are connected by a constraint. Such a constraint, between distinct objects, is typically not expressible within the traditional object-oriented framework.