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.
Each ECLiPSe prompt (eg[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
[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
The programmer enters
lib(structures). to which the system
I have added a star to the beginning of each line showing a system
Query 2 defines the attributes for objects in the classes task and
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
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.