Re: OO puzzle

["Matthew Heaney" <matthew_heaney@acm.org>]

In article <386CFDEB.946C3336@shadow.net> , Jeffrey L Straszheim 
<stimuli@shadow.net>  wrote:

> Of course it's not the same: no two different things are ever the
> same.

To use Peter Wegner's terminology, it's the difference between "type
semantics" and "template semantics."

What "type semantics" means is that for a (scalar) type, you constrain
the range of possible values.

What "template semantics" means is that for a (tagged type) class, you
constrain the set of possible types, and therefore constrain the set of
operations possible.

So you are comparing apples and oranges.  If you're going to grok the
Ada way of doing things, you have to think in terms of

1) scalar types with their constrained ranges
2) array types with their index constraints
3) discriminated records with their discriminant constraints

and

4) tagged types and class-wide programming


> The point is Ada allows me to do this:
>
> In some package specification:
>
>  function Some_Opaque_Library_Function (Param: Integer) return Integer;
>
> In my code:
>
>  The_Largest_Fred : constant := 135;
>  subtype Fred is range 0 .. The_Largest_Fred;
>
>  A_Variable       : Fred := 0;
>  Another_Varialbe : Fred;
>
>  begin
>
>    Another_Variable := Some_Opaque_Library_Function (A_Variable);
>
> ...
>
> Now, nothing guarantees that the constraint for subtype Fred won't
> be violated here, causing a runtime fault.

Of course, because you-the-client made an unjustified assumption about
the return value of the function, by assuming a smaller range than was
specified in the function profile.

If there's a run-time error, then it's your fault for assuming a
stronger postcondition than was guaranteed by the function
specification.


> (BTW, this is the sort
> of place where DBC really helps, but I won't belabor that point.)

Then use DBC.  Declare your library function as returning subtype with a
smaller range:

  subtype Fred is Integer range 0 .. 135;

  function Some_Opaque_Lib_Func (Param : Integer) return Fred;
...
  Variable : constant Fred := Some_Opaque_Lib_Func (P);

Now you really do have a guarantee that no run-time fault will occur
(assuming of course the function is error-free, and satisfies its
postcondition).


> Now, one can debate whether this is a (potential) type error. If
> so, the debate becomes a semantic one and a waste of time, but
> let me just say that by some definitions of type, this is indeed
> considered a type error. Again, I'd prefer not to belabor the point.

The only "definition of type" that you should care about on CLA is the
Ada definition.  In Ada, there is no type error in your example!

A "type error" --as defined by Ada-- would have been caught at compile
time.  For example:

  type Barney is new Integer;

  B : constant Barney := Some_Opaque_Lib_Func (P);

This assignment is illegal, and will be caught at compile time, because
Barney is a different type from Integer.

Your original example had a "constraint error," because you violated the
range constraint of the object (which had subtype Fred).  It is not a
type error.