Re: Ada OO Mechanism

[Samuel Mize <smize@imagin.net>]

Hyman Rosen <hymie@prolifics.com> wrote:
> Samuel Mize <smize@imagin.net> writes:
>> There are other OO design approaches that are harder to implement in
>> C++ than in Ada, because C++ strongly supports one specific view of
>> object-oriented technology.
> 
> Could you give an example of this?

I confess that I can't just pop up an example.  My non-C++ and
non-Ada object-oriented systems was (good grief) over a decade ago,
and I'm not all the way up the learning curve in C++.

Let me try to get someone else involved who will (I think) be able
to give you a better answer, ask you a question, and give you a
"reasonable" argument to consider.  I grant that this is weak.

THE SOMEONE ELSE is a frequent poster here, but I don't want to
drag him into a thread if he's intentionally ignoring it.  I'll email
him a copy of this posting.  He has said that he does object-oriented
development, but that he does not prefer the C++ model.  I have to
assume he routinely does things that don't fit well into that model.
I hope he will discuss (or give a pointer to previous discussion)
what method he prefers, and why it is incompatible with C++.

THE QUESTION: how does one do "mix-in" classes in C++?  I'd bet a
nickel that you can, but I don't know the specific mechanism.  The
"mix-in" metaphor is described in the Ada 95 Rationale, 4.6.2.

THE "REASONABLE" ARGUMENT: C++ supports a very specific view of
object-oriented development.  I'll list several things that I
believe are true about C++ (feel free to correct errors).  Each
of them represents a methodology decision.  Perfectly good methods
can be derived where each or all of these is false.  In that case,
C++ would not support that method well.

- The class is the primary form of data encapsulation.  (I have
  seen C++ advocates argue that Ada is weak because it provides
  encapsulation outside classes.)

- Each "message" (implemented as a dispatching function call) goes
  to exactly one object (or class).  Any other objects mentioned are
  passive arguments.

- When an object sends a message, it waits for the called object
  to complete its processing of the message (that is, for the return
  of the function call) before continuing.

- One thread of control calls all objects; they are not independent
  active entities.

Now, all reasonable languages are Turing-equivalent.  I'm sure one
could create, in C++, a system where all the objects are active
and objects send each other messages without waiting for a response;
or, one where several objects can work together co-equally to handle
some messages; or one where object-level messages go to a queue in
the object's class, and whatever object becomes free handles the
next message from the queue.  But each of these would be working
against the object-oriented model built into the language.

With Ada, one can do these things without working against the OO model
of the language, because the OO model is more general.  On the other
hand, for work within the OO model of C++, you don't have as much
method-specific support built into the language.  On the other other
hand, it's fairly easy to define a method in Ada where one gets a very
C++ "feel."  Mandate that every tagged type will be defined in its own
library-level package, with nothing in that package except for the
tagged type and its supporting class-level elements; every potentially
dispatching subprogram must have a controlling first parameter.  Voila,
C++ style!  The package is the equivalent of the "class" in C++.

I'm not saying that C++ is "lesser," "worse" or "wrong," I'm just saying
that it takes a different, but equally valid, design approach.  The
same is true for Ada.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam