Re: advantages or disadvantages of ADA over pascal or modula

[Martin Klaiber <martinkl@zedat.fu-berlin.de>]

karl bowl <karl.bowl@gmx.de> wrote:

> I would like to ask anybody to tell me about advantages or
> disadvantages of ADA(95) over pascal or modula(2).

I'm only an Ada-beginner, but I'd say that Ada is so much more powerful
than Pascal that they hardly can be compared at all. But I also found
three things which I miss in Ada compared to Borland Pascal.

First, it would be nice, if an object in Ada would know it's own
variables without naming them explicitly.

  type type_Object is
    tagged record
      A_Variable : A_type;
    end record;
  procedure Add (Objectname : type_Object);

  -- body:
  
  Add (Objectname : type_Object) is
  begin
    A_Variable := A_Variable + A_Value;
  end Add;
  
instead of:

  Add (Objectname : type_Object) is
  begin
    Objectname.A_Variable := Objectname.A_Variable + A_Value;
  end Add;
  
It's not a big thing, but sometimes it leads to a lot of writing. Yes,
I know I can rename variables, but I still wonder why an object in Ada
doesn't know it's own variables.

Second, it would be nice, if Ada would allow to change internal
variables of an object also in functions. So, the following is not
valid code but it would be nice if it was, IMHO.

  type type_Calendar is
    tagged record
      Month : type_Month;
      Year : type_Year;
    end record;
  function IncMonth (Calendar : in out type_Calendar) return boolean;
  function IncYear (Calendar : in out type_Calendar) return boolean;
  
  -- body:
  
  function IncMonth (Calendar : in out type_Calendar) return boolean is
    ret_val : boolean := true;
  begin
    if Calendar.Month = 12 then
      if IncYear (Calendar) = true then
        Calendar.Month := 1;
      else
        ret_val := false;
      end if;
    else
      Calendar.Month := Calendar.Month + 1;
    end if;
    return ret_val;
  end IncMonth;
  
  function IncYear (Calendar : in out type_Calendar) return boolean is
  begin
    if Calendar.Year < 3000 then
      Calendar.Year := Calendar.Year + 1;
      return true;
    else
      return false;
    end if;
  end IncYear;
  
Of course the same thing can be done with procedures and a boolean
parameter. But IMHO it's less elegant and less intuitive. I already
had a discussion about that, and people told me that the above is
forbidden to avoid side-effects. But I don't see any side-effect
here. The functions and the variables to be changed belong to the
same object, and to my opinion it would not be dangerous to allow
also functions to change these variables.

This is at least my view as a human. Internally these variables
might be represented as anything else. But to me one of the main
qualities of oo-code is the community of variables and the functions
and procedures to work on these variables. So, I just find it a bit
strange that something like above is not allowed.

The third thing I miss in Ada is something like the 'inherited'
statement in BP. If you have code like this:

  type type_Printer is
    tagged record
      ...
    end record;
  procedure Initialize (Printer : type_Printer);
  
  type type_Inkjet_Printer is new type_Printer with
    record
      ...
    end record;
  procedure Initialize (Inkjet_Printer : type_Inkjet_Printer);
  
  -- body
  
  procedure Initialize (Inkjet_Printer : type_Inkjet_Printer) is
  begin
    Initialize (type_Printer (Inkjet_Printer));
    ...
  end Initialze;

and later change the object structure to:

  type type_Printer is
    tagged record
      ...
    end record;
  procedure Initialize (Printer : type_Printer);
  
  type type_Line_Printer is new type_Printer with
    record
      ...
    end record;
  procedure Initialize (Line_Printer : type_Line_Printer);
  
  type type_Inkjet_Printer is new type_Line_Printer with
    record
      ...
    end record;
  procedure Initialize (Inkjet_Printer : type_Inkjet_Printer);
  
the compiler doesn't (cannot) realize in the Initialize-procedure above
that Inkjet_Printer is now calling a wrong Initialize-procedure itself
(the one from type_Printer, instead of the one from type_Line_Printer).
It already took me hours to find such errors. With such an inherited
keyword we could write instead

  procedure Initialize (Inkjet_Printer : type_Inkjet_Printer) is
  begin
    Initialize (inherited (Inkjet_Printer));
    ...
  end Initialze;

and would always call the Initialize-procedure of the type the object
is inherited from. Of course this does not avoid all errors as someone
might really want to use a procedure from a further type. But I suggest
this person would use the name of this procedure anyway.

Well, instead of the inherited-statement, it would also be helpful, if
the compiler would give a warning in such cases.

Martin