Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus <see.reply.to@maps.futureapps.de>]

Cesar Rabak wrote:
> Colin Paul Gloster escreveu:
>> On Wed, 22 Jul 2009, Simon J. Wright wrote:
>>
>> |--------------------------------------------------------------------|
>> |"[..]                                                               |
>> |                                                                    |
>> |And what will happen to this distinction with Point (2.0, 2.0);?    |
>> |                                                                    |
>> |You could use named parameter association, but *much* better to use |
>> |proper types --                                                     |
>> |                                                                    |
>> |type Cartesian_Coordinate is record                                 |
>> |   X : Metres;                                                      |
>> |   Y : Metres;                                                      |
>> |end record;                                                         |
>> |                                                                    |
>> |which makes it easy to (for instance) create appropriate functions  |
>> |"+", "-", "*", "/"."                                                |
>> |--------------------------------------------------------------------|
>>
>> Oh dear, Mr. Wright is nearly as bad as Mr. Rabak. Dr. Meyer gave an
>> example of overloading which Eiffel can perform 
> 
> Since you citing me (incorrectly) and write this:
> 
>> which he claimed that
>> Ada can not manage. 
> 
> Writing a wrong assertion about a book it seems you only read a summary
> made before a term exam, I suggest you get the text you implied you were
> mentioning, specially the four paragraph on page 94 (OOSC 2nd ed.) and
> pay attention to was is *actually* written there.

Not being a fan of identical names for things not overridden
(SPARK avoids this for Ada), the crux is, I think, allowing
REAL into the discussion:

  new_point (p, q: REAL): POINT

First, this is likely a create routine of POINT, REAL does not
affect dispatching, POINT does.  But when a new routine
should make a new point from parameters of some other type,
not REAL, we can, per advice, use a name that differs from
`new_point` .  And then we may refer to the
"principle of non-deception" which will excuse us for not
having, neither in Ada nor in Eiffel, Multiple Dispatch or,
more Ada-like, many controlling parameters (dispatch smells
of run-time things).

And there's the problem, really. (*)

(Not so much in syntactic vs semantic overload, purported to
require dynamic dispatch, which is not the case for Ada
or whenever the compiler can infer the run-time type. I think
that even some SomeDialectOfEiffel has made an attempt in this
direction.)

`new_point` is using an unspecific type REAL.  Something
that we should not do, using Ada.  REAL says little, except
perhaps that the programmers make certain assumptions.
Hopefully, they have augmented their unspecific REAL with a
"require" for `new_point' documenting at least the range of
permissible values or some such.  Now "require" is presented as
the "answer", and means of "non-decpetion" when overriding
does use the same name as the overridden routine. (p.95)
You could call it a workaround, though, for there is a
better solution for method selection than principles.

Still nothing wrong with using numeric types that are not as
vague as REAL.  For example,

  function new_point (p, q: EUCLIDEAN_DISTANCE) return POINT;

New and distinct parameter types (that in general have compile
time and run-time effects, hence are more than nicknames) are
not a perfect solution, because the distinction doesn't work
in all contexts.  But still, I don't understand why a language
design that puts the spot on types (O-O, modules, contracts, ...)
starts coming up with all kinds of selected "principles" and
"answers" when it comes to the lack of O-O in its elementary
types, like INTEGER.  Or maybe it is no good advertising when
one would have to say, too difficult at the time; of the O-O
model as made does not work well with elementary objects;
or some such?


Another, minor, flaw in this discussion is that Meyer, perhaps for
reasons more or less obvious, refers to Ada 83 when he writes
Ada; an exception is �33.7. (Interesting � in itself IMO.)

(*)
package Points is

   type Euclidean_Distance is digits 5 range 0.0 .. 45_000_000.0;

   type Point is tagged private;

   function New_Point(P, Q: Euclidean_Distance) return Point;


   type Near_Point is new Point with private;

   type Neighbourhood_Distance is new Euclidean_Distance
     range 0.0 .. 450.0;

   not overriding
   function New_Point(P, Q: Neighbourhood_Distance)
     return Near_Point;


private
   type Point is tagged record
      X, Y : Euclidean_Distance;
   end record;

   type Near_Point is new Point with record
      Blocks: Boolean;
   end record;
end Points;