| # Examples 8.1.2.3: ELT_LT |

The single feature of the required library class ELT_LT is used in individual examples below. None of the examples given is a complete class nor necessarily a 'complete' method.

In all of the examples it will be assumed that the code shown is in a class called, say, EXAMPLE.

#### elt_lt

This feature provides a test for ordering which is based either on value ordering (if the object derives from $IS_LT) or object ordering - if not immutable! Consider the following four example cases -

first : CARD := 42 ;
second : CARD := 27 ;
res : BOOL := elt_lt(first,second)

which is valid because the type CARD derives from $IS_LT and gives res the value false. Contrast this with -

first : ARRAY{CARD} ;
second : ARRAY{CARD} ;
res : BOOL := elt_lt(first,second)

which makes res also false - but this time because neither are objects - they have not yet been created! This kind of error is very easy to fall into, even for quite experienced O-O programmers! Look, however, at the next example -

first : ARRAY{CARD} := ARRAY{CARD}::create(5) ;
second : ARRAY{CARD} := ARRAY{CARD}::create(5) ;
res : BOOL := elt_lt(second,first)

What is the value of res under these circumstances (noting the order of arguments to the call)? There are two created objects - although they do not themselves have an equality test. Contrast that with -

first : ARRAY{CARD} := ARRAY{CARD}::create(5) ;
second : ARRAY{CARD} := ARRAY{CARD}::create(5) ;
res : BOOL := elt_lt(first,second)

for which, at last, res may be true - but only if the implementation-defined object ordering relation has been specified in this way! Oh! By the way! That must mean that res could also have been true in the previous example! Whichever rule is defined by the implementation these last two examples must have the same result!!

| Specification Index |  | Language Index |  | Section 8 Index

Comments or enquiries should be made to Keith Hopper. Page last modified: Thursday, 25 May 2000. |