Re: Magic ordering

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 15 Mar 2005 16:21:25 +0000, Marius Amado Alves wrote:

> On 15 Mar 2005, at 15:08, Dmitry A. Kazakov wrote:
>> There could be many orders defined on the same objects, as Hyman 
>> rightfully pointed out. But any of them have to be published in the contract. 
>> There is nothing outside the contract.
> 
> There may be multiple contracts overlapping, or even disjoint, 
> associated with the same type.

I would say that are subtypes of the type.

> That's how most systems are constructed. 
> For example a part of the program gives you a contract for the deep 
> meaning e.g. retrieve the person's name given the SS number. Another 
> part is a contract that ascertains if the number is in a given set. 
> They overlap. The latter does not need the name. The former does not 
> need the set. I know this design is not an OO pearl, but it works, 
> there's nothing wrong with it, and is present in most systems I've seen 
> or built.

This is how Ada generics work. When instantiated you can reroute operations
to satisfy the contract. It is also possible to do with tagged types, no
wrappers needed:

type X is tagged null record;
function "<" (Left : X; Right : X'Class) return Boolean;
function ">" (Left : X; Right : X'Class) return Boolean;

type Y is new X with null record; -- Swap "<" and ">"
function Less (Left : Y; Right : X'Class) return Boolean renames "<";
function Greater (Left : Y; Right : X'Class) return Boolean renames ">";
function "<" (Left : Y; Right : X'Class) return Boolean renames Greater;
function ">" (Left : Y; Right : X'Class) return Boolean renames Less;

> On the (non-OO) extreme of this theory, there are no objects, just 
> operations, a subset of which constitute each contract (well, each 
> interface). I've been using formal packages a lot lately as an 
> approximation of this.

But that's the same. Whether it be stated or deduced contract, there is
one. The only difference is that the latter cannot be efficiently evaluated
neither by the compiler nor by the programmer.

> But we diverted very quickly from the mainline, creating an order for a 
> type. As I said, I believe there's always a way: but it must be done 
> case by case. Show me your type, and I'll show you a way. If there's no 
> way I'll ask you: why do you want to order this type? If you show a 
> good reason, I'll (hopefully) be able to identify the design fault.

OK but it is responsibility of the type designer to provide you with a
comparison.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de