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-08 03:16:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!iad-peer.news.verio.net!news.verio.net!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: Wed, 8 Jan 2003 12:13:18 +0100 Organization: Freie Universitaet Berlin Sender: Martin Klaiber Message-ID: References: <17cd177c.0301080101.3f826bab@posting.google.com> NNTP-Posting-Host: martinkl.dialup.fu-berlin.de (130.133.237.205) X-Trace: fu-berlin.de 1042024606 16193702 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:32737 Date: 2003-01-08T12:13:18+01:00 List-Id: Gautier wrote: > Martin Klaiber: >> First, it would be nice, if an object in Ada would know it's own >> variables without naming them explicitly. > In fact, you are missing BP's prefixed OO notation (object.Method). > You will certainly find fierce debates in c.l.a archives about it. Yes, I've read some of these debates. I don't prefer one notation over the other. Both have their advantages and disadvantages IMHO. > The explicit has maybe the merit of readability over concision Hm, depends on. Redundancy can affect readability too. >> Second, it would be nice, if Ada would allow to change internal >> variables of an object also in functions. > Also subject to debates... you say it's intuitive because you are > accustomed to it. Yes, that might be true. > But look at your example. Normally, the basic role of a function is to > give a value in function of other (the parameters). Here the parameter is in the function-name. I could have written it also as (skipped a bit to keep the line short): function IncMonth (Calender : ...; Days : Positive) return boolean; > In your case the main information is what you do to "Calendar" and the > result has a minor role - quite strange... Well, this depends on how you want to use such functions. I like to use them like that: if IncMonth (Calendar) = true then Update (Anything); end if; > It would be more elegant and intuitive (and also efficient) to write > procedure IncMonth (Calendar : in out type_Calendar) is > begin > if Calendar.Month = 12 then > IncYear (Calendar); > Calendar.Month := 1; > else > Calendar.Month := Calendar.Month + 1; > end if; > end IncMonth; > procedure function IncYear (Calendar : in out type_Calendar) is > begin > if Calendar.Year < 3000 then > Calendar.Year := Calendar.Year + 1; > else > raise Year_out_of_range; > end if; > end IncYear; Will this really work like that? Calendar.Month must not be set to 1 if IncYear fails. Does this mean, if exception Year_out_of_range is raised, the rest of the code in IncMonth will be skipped? > Don't forget, you have the exceptions... it saves a lot of transporting > error codes and acrobatic expressions... Yes, these exceptions are phantastic. I really have to get used to them. Martin