Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney <matthew_heaney@acm.org>]

nabbasi@earthlink.net writes:

> offcourse a type is defined as set of values and set of operations.

Yes.

> I find it very hard in Ada to visualize an tagged object. but I can 
> easily visulaize a class object in Java or C++ becuase the class construct 
> makes it easy for me to do that.

I don't understand your problem:

   type T is tagged private;

is exactly equivalent to

   class T {...

in C++.


If the features of a type aren't obvious from reading the text of an Ada
program, then something is probably wrong with the program, not the
language itself.

> when I used Ada, I use it as an object-based (as opposed to object-oriented)
> langauge, which is what Ada was originally designed as, I do not use Ada for 
> its OO features. I like Ada as a procedural/object based, and for that it 
> is great. plus I think all the OO/inhertence stuff is way overrated
> any way.

Pete Wegner has done a lot of damage, I'm afraid.  His classification of
Ada 83 as object-based is incorrect.  Ada 83 is properly classified as a
type-based language (his term was "class-based," but I want to stick to
Ada terminology).

The addition of tagged types in Ada 95 is good, but it doesn't change
implementation techniques that much from Ada 83, because you should
already be using type-based abstractions where that makes sense.  (I
give some advice for knowing when to use a package vs when to use a type
in the design patterns archives at the ACM website.  Search for
"singleton".).

I agree, by the way, that inheritence as a re-use mechanism is way
overrated.  All it does is increase coupling, and make (deep)
hierarchies too sensitive to changes in the classes near the root.  Ada
provides composition mechanisms that don't require inheritence.

This means that if you're building deep inheritance hierarchies in Ada
95 ("deep" defined as more than 2 or 3 levels), then you're probably
doing something wrong.  Any normal system is going to require changes as
it is built, so you'll have the compile-the-universe problem every time
there's a change.

> abstraction, data hiding, sepration of interfaces and implementaions, strong
> typing, generics, good exception, good build-in tasking model, and all 
> that good stuff is good enough for me. If I want to do heavy/pure
> OO stuff, I would not use Ada, just becuase I am not used to the OO 
> ways of Ada, it just too different from all the other OO languages 
> out there (different in how its OO features are reprsented offcourse,
>  the semactics are the same, but language representation (lexical
> structure) is very important I think becuase it affect how one thinks
>  and visualize things), and in that the class structure is more natural than
> tagged records + procedures that takes paramters or returns paramters
> of types of that record.

How you do it in Ada 95 is not much different from how you do it in Ada
83.  If you think Ada 95 is "too different" from other oo languages,
then you must think the same think about Ada 83, right?

The Ada way has some advantages, because I can say this:

   if O1 = O2 then ...;

instead of the klunky

   if O1.Is_Equal (O2) the ...;