From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,912597791e813f68 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-07 10:32:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fu-berlin.de!uni-berlin.de!martinkl.dialup.fu-berlin.DE!not-for-mail From: Martin Klaiber Newsgroups: comp.lang.ada Subject: Re: advantages or disadvantages of ADA over pascal or modula Date: Tue, 7 Jan 2003 19:14:35 +0100 Organization: Freie Universitaet Berlin Sender: Martin Klaiber Message-ID: References: NNTP-Posting-Host: martinkl.dialup.fu-berlin.de (130.133.237.205) X-Trace: fu-berlin.de 1041964354 15837992 130.133.237.205 (16 17 18) X-Orig-Path: not-for-mail User-Agent: tin/1.5.12-20020427 ("Sugar") (UNIX) (Linux/2.4.20 (i586)) Xref: archiver1.google.com comp.lang.ada:32687 Date: 2003-01-07T19:14:35+01:00 List-Id: karl bowl 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