Re: Ada OO Mechanism

[Samuel Mize <smize@imagin.net>]

I'm combining responses to two messages here.

Hyman Rosen <hymie@prolifics.com> wrote:
>Samuel Mize <smize@imagin.net> writes:
>> 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.

Then you answered the question.  Thanks; I figured one could do it.

I'm using lines of "- " to separate major sections.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - The class is the primary form of data encapsulation.
>
>Classes support static data and function members, and nested classes.
>I believe that this gives C++ the equivalent of Ada's packages.

The difference is that, in Ada, encapsulation is distinct from the
object-oriented notion of "class."  Certainly a C++ class provides
encapsulation.  It also provides more, and this may cause confusion
when you want to encapsulate something without indicating that it
meets the OO notion of a "class."

There may be object-oriented approaches that uses this distinction,
but I don't have a reference handy, and I don't make this claim.

I do know that this distinction is extremely useful in a mixed-method
environment, e.g., object-oriented and procedural elements working
together.

That doesn't directly address "an OO method that's harder in C++."

It does point out that an OO/procedural integrated system may be less
clear in C++, as the reader must determine which classes are classes,
and which classes are not classes but just encapsulations of
non-class entities.  So, if we consider mixed-method programming to
be a form of OO, we can argue that this is a form of OO that is not
as well supported by C++ as by Ada.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - Each "message" (implemented as a dispatching function call) goes
>>   to exactly one object (or class).  Any other objects mentioned are
>>   passive arguments.
>
>How is this different from Ada? Does Ada allow dispatching on more than
>one argument?

Yes, see my other message.  As you noted in reply to it:

>Samuel Mize <smize@imagin.net> writes:
>>   -- This dispatches on both parameters, so they have to match
>>   -- at run-time
>>   procedure Operation_4 (A: A_Type; B: B_Type);
>
>(Do you mean B: A_Type ?)

Also, to your question:

>When you say "match at runtime" do you mean that their dynamic types
>must be the same? Does the code raise an exception if they happen not
>to match?

I'll detail this for you in a while, but I need to refer back to the ARM
and bone up first.

>If I were to code this in C++, I could do the following:
>
>   void Operation_4(A_Type &A, A_Type &B)
>   {
>      if (typeid(A) != typeid(B))
>         throw "Mismatched types!";
>      A.Operation_4(B);
>   }

You can manually code it up, but that doesn't mean the language
supports it -- rather the reverse.  By a similar argument, one can
claim to do full-up object-oriented programming in C.  Indeed, the
X-windows system is done that way (or used to be, anyway -- I haven't
looked at it for a few years).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - 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.
>
>Well, no argument there. C++ does not have a language-defined parallel
>processing capability, and Ada is absolutely superior in that regard.
>However, I would say that this is generally considered orthogonal to
>object-oriented programming, since your statement above is equally true
>if you replace objects and messages with plain function calls.

There are object-oriented methods of analysis and design that view
all the objects in a system as inherently parallel, independent
actors.  This is called the Actor model, and there are languages that
encapsulate it.  In this method, parallel independent execution is
not orthogonal to object-oriented programming; the method considers
independence of execution to be integral to their definition.

I don't say that OO programming inherently includes parallelism.  I
do say that there exist methods of OO programming which consider
parallelism integral to the definition of an object.  

>I think including parallel behavior in your definition
>of OO is stretching that definition beyond any accepted usage.

My assertion was that there are OO methods that are harder to implement
in C++ than in Ada.  Here is an example.  The fact that single-thread
OO methods don't consider parallelism to be integral to the concept of
"objects" does not invalidate other method that do.

It isn't as popular as the C++ model, as I said.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> Did you intend that paragraph to sound contentious?  To my ear,
>> at least, it has rather a "you're all liars, I'm naming names"
>> sound to it -- I hope that isn't what you meant.
>
>I wanted it to sound somewhat contentious. The named people each
>claimed ...
>There were responses, but no code, so I got a little testy.

Well, that's too bad.

There is a class of people (in Ada terms, a type :-) called a
net.loon.  I don't think you are one.

But one thing that net.loons often do is to demand that some other
poster provide hard evidence, right away, in whatever form they deem
most appropriate, to support some stray comment.

When the evidence doesn't show up on demand, the net.loon's next step
is to demand that the other poster publicly admit not only that they
might be mistaken, but that they were out-and-out lying and knew it.
Following this come other accusations, obscenities, and sometimes mail
bombs and other electronic harassment.

I think you can see why people would just ignore or kill-file anyone
who seems to be starting down that road with them.

So I would strongly suggest that you take a more "chilled out"
approach in posting.  Understand that people may hold and express
opinions without having statistics or code examples handy to support
them.  They may even hold and express opinions with nothing behind
them but hot air, and that's perfectly OK on the net.

They may also not see your question for days, if at all.  News
propagation can be unreliable.

And, most of us have lots of other things to do, like making a
living and living a life, and digging up specifics for a net argument
is way down on our list of priorities.

Especially when someone focuses in on one sentence out of a 175-line
post, ignores the rest of it, and bears down demanding hard evidence;
and after a couple of days, starts throwing my name around in another
post as one of Those People who didn't deliver evidence on demand.

And that's about as contentious as I want to get on the net.  I
hope to have fruitful and pleasant discussions with you in the future.

Best,
Sam Mize

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