Re: on OO differnces between Ada95 and C++

[ddavenpo@redwood.hac.com (Darren C Davenport)]

Nasser Abbasi (nabbasi@qualcomm.com) wrote:


: Hello,

: I have a simple comment, but probably a long way of 
: showing it :)

: I have been playing around with the OO features in Ada95 and
: comparing it with C++. I noticed this little difference, and I'd
: like to see what you think of it.

: Lets assume we have a base class called Account, and a class called
: Saving_Account that uses Account as base. 

: Lets also assume that we need to define a Money Type, defined in
: the base class Account.     

: In Ada95 this type is defined in the package Account.ads that also
: includes the definition of the tagged record type Account (along with
: operations that act on Account type).

: In C++, this Money Type is typedef'ed inside the public part of the
: class Account, and it becomes part of the public interface of the
: base class.

: so far so good.

: Now, In Ada95, a client that wishes to use Saving_Account type (and
: any operations on it) will "with" the Saving_Account Package.

: Also, in C++, a client who wishes to use Saving_Account class will
: include "saving_account.h"

: There is some differences though.

: In C++, the client to the saving_account class can also use the
: Money_Type type (even though that is defined in
: the base class Account) without having to include base class
: "account.h", this is because Money_Type has become a public part of the
: Saving_Account class when Saving_Account inherited Saving class.

: In Ada95, the client of Saving_Account has no viability to Money_Type
: type definition even though they with'ed Saving_account package, since
: Money_Type is not a "inherited" by the Saving_Account package
: from the Account package. This means that in Ada95, If one wants to
: access things like type definitions that are not tagged, but 
: used in defining components inside the tagged record, one must
: "with" the client package and also packages that the client package
: with'ed just to be able to have viability to those type definitions.

The other option is to to put Saving_Account_Type into to a child
package of account, say account.savings.  Then when you with account.savings
you get the anything the parent package has that's visible.

Darren