Ada OOP model; support from a C++ example

Ada OOP model; support from a C++ example

[Richard A. O'Keefe]

There's been a bit of debate about the Ada OOP model recently.
I thought it would be illuminating to take a real example from someone
else's real published C++ code to show how the C++ model creates an
entirely artificial problem which is absent in Ada 95.

First, to help you judge the quality of the source, let me quote
from "About the Author" (of the example):

	<Mr X> is an internationally recognised authority on software
	engineering (project management, software documentation, cost
	estimating, risk analysis), C and C++.  He lectures frequently,
	writes numerous articles, and has written many widely
	recognised books.  ...  His work is noted for its clarity and
	readability ... He is Senior Associate with the consulting firm 
	<Y> [a very very large firm indeed].

Second, to help you judge the quality of the source, let me quote what
he says about complex numbers:

	In complex numbers, you can think of the real portion as
	representing the amplitude of the number, while the imaginary
	part represents the phase.

(How come someone like this is a consultant with a Top Form and I'm not?)

Anyrate, here's the example.  He has a string class (this book was
published in 1994) called WStr.  He wants to be able to mix WStr strings
and C char* strings.  So

	class WStr : Tstreamable {
	    ...
	    BOOL operator < (WStr &sString);
	    Bool operator < (char *szString);
	    friend BOOL operator < (char *szString1, WStr &sString2);
	    ...
	};

By the way, the two different spellings of BOOL/Bool are not a typo on
my part.  The whole pattern, including the two spellings of bool, is
repeated for each of the 6 comparison operators.

Here's the problem.  In C++,
	left OP right
can stand for either the method call
	left.(operator OP)(right)
or the function call
	(operator OP)(left, right)

So if you want an operator to work on an operand of type T, it be a
method of type T if and only if the FIRST operand is of type T.  Here
we want
	Wstr <OP> Wstr		- ok, can be inside Wstr
	Wstr <OP> char*		- ok, can be inside Wstr
	char* <OP> Wstr		- OOPS!  can't be inside Wstr.

In Ada, if we had

	type WStr is new Tstreamable with ...

	function "<"(Left: WStr; Right: WStr) return Boolean;
	function "<"(Left: WStr; Right: String) return Boolean;
	function "<"(Left: String; Right: Wstr) return Boolean;

there would be no such assymetry:  ALL of these functions, needing to
know about the implementation of WStr, could and would be inside the
same encapsulation boundary.

But wait, there's more!  Only the operations declared inside the class
are dispatching operations!  If we derived a subclass of WStr (call it
WShortStr for example) it could inherit the Wstr.Wstr and Wstr.String
versions of the operator, but it could not inherit the String.Wstr
version.  But the Ada approach permits ALL versions of the operator to
be dispatching, if that is what you want.

Of course with strings there are other operators that you would like,
such as concatenation, and here again you would like
	  Wstr & String
	  Wstr & Wstr
	String & Wstr
which can all be inside the same encapsulation boundary in Ada but not
in C++.

I am not claiming that you cannot obtain the desired effect in C++.
I've an idea something could be done with templates, and then of course
there is implicit coercion.  What I am claiming is that you can't do it
the _obvious_ way, and that this "expert" didn't even try.

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.