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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6b6619eb9cada212
X-Google-Attributes: gid103376,public
From: "DuckE" <nospam_steved@pacifier.com>
Subject: Re: Help me to chose between ADA 95 and C++
Date: 1999/12/13
Message-ID: <3855af39.0@news.pacifier.com>#1/1
X-Deja-AN: 560364541
References: <01bf37fb$a91afb60$0564a8c0@IS-D2D04C.test>
 <B46461D2.259F%Harald.Schmidt@tomcat.de>
 <829rbv$a8m$1@nntp6.atl.mindspring.net> <01bf3e32$0b9dc880$022a6282@dieppe>
 <385112AE.7E2CFA9@rdel.co.uk>
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Trace: 13 Dec 1999 18:45:13 PST, 216.65.140.120
X-MSMail-Priority: Normal
Reply-To: "DuckE" <nospam_steved@pacifier.com>
Newsgroups: comp.lang.ada
Date: 1999-12-13T00:00:00+00:00
List-Id: <comp.lang.ada>

Chris Powell <chris.powell@rrds.co.uk> wrote in message
news:385112AE.7E2CFA9@rdel.co.uk...
[snip]
>
> I would not recommend Ada 95 for OO development. Okay, it has all the
> benefits of Ada 83 for type safety, etc, but the syntax of its class
> programming constructs seems to make the code long winded, obscure and
> error prone. I can give examples if anyone is interested/disagrees.
>
Please do post an example or two to the newsgroup.  Not because I doubt your
statements, but because someone might post suggestions on how to improve the
code.

I wrote my first OO Ada95 program about 6 months ago.  It is working well
and has benefited from the use of inheritance in adding new objects.  But I
do find some of the references to objects messy.  I would be interested in
seeing examples of how to do things better.

BTW: The only significant feature of Ada95 object definitions that I really
don't like is the implicit range of an objects definitions.  This is
somewhat inconsistant with other parts of the language.  For example: an
"IF" statement is always ended by an "END IF", making the extent of the
object quite clear.  When looking at tagged record definitions and the
methods defined following the records, careful study and knowledge of
"freezing rules" is required.  I would have much preferred a syntax where
the start and end of an object and its methods are explicitly defined.

SteveD