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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: "Matthew Heaney" Subject: Re: Help me to chose between ADA 95 and C++ Date: 1999/12/14 Message-ID: <38566d0a_4@news1.prserv.net>#1/1 X-Deja-AN: 560575465 Content-transfer-encoding: 7bit References: <01bf37fb$a91afb60$0564a8c0@IS-D2D04C.test> <829rbv$a8m$1@nntp6.atl.mindspring.net> <01bf3e32$0b9dc880$022a6282@dieppe> <385112AE.7E2CFA9@rdel.co.uk> <3855e3cd_1@news1.prserv.net> <38561A6C.5DE3D901@rdel.co.uk> Content-Type: text/plain; charset="US-ASCII" X-Complaints-To: abuse@prserv.net X-Trace: 14 Dec 1999 16:15:06 GMT, 32.101.8.60 Organization: Global Network Services - Remote Access Mail & News Services Mime-version: 1.0 Newsgroups: comp.lang.ada Date: 1999-12-14T00:00:00+00:00 List-Id: In article <38561A6C.5DE3D901@rdel.co.uk> , Chris Powell wrote: > C++ encapsulates methods and data in a single structure. In Ada, class > methods are defined outside the object type so do not appear to 'belong' > to the type. The enclosing package defines what operations are primitive for a type. So of course the operations are declared "in the type," because they're in the same package: package Apples is type Apple_Type (<>) is tagged limited private; procedure Eat (Apple : access Apple_Type); ... end Apples; Procedure Eat is a primitive operation of type Apples. That's not obvious? > Having to explicitly pass the object instance as a parameter (the > implicit 'this' in C++) further separates the logical association > between methods and objects. When I see the procedure declaration: package Stacks is type Stack_Type is limited private; procedure Push (Item : in Item_Type; On : in out Stack_Type); ... end Stacks; it's perfectly obvious that it's a primitive operation for stacks. When I see the procedure invocation: Push (Item, On => Stack); it's perfectly obvious that Push is operating on a stack object. So I don't buy your argument that the syntax "separates the logical association between methods and objects." Note also that the Ada95 syntax simplifies binary operations: Marry (Adam, Eve); is a lot more natural than Adam.Marry (Eve); > I am a Multiple Inheritance fan, because I think I know how to use it > properly. I do not believe it (always) indicates a bad design, as some > do. Ada 95 has some constructs to allow different types of MI, but not > all provided by the more general approach of C++, and again, the syntax > is obscure involving tagged types within generics, access discrimiated > records, etc. In C++ you simply define an X as a Y and a Z. In Ada, the > syntax would have been (if allowed): > > type Object is new X.Object and new Y.Object with record .... Yes, you have to understand how to use access discriminants (to do MI) and generic formal tagged types (to do mixin inheritance). The MI and mixin idioms are built on existing language features, so this keeps the language itself simpler. I could argue the point the other way. In C++, the keyword "virtual" is used so often for so many different things, that it's hard to keep them all straight.