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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e5eb8ca5dcea2827 X-Google-Attributes: gid103376,public From: Samuel Mize Subject: Re: Ada OO Mechanism Date: 1999/05/25 Message-ID: <7if7oj$bee@news1.newsguy.com> X-Deja-AN: 482092373 References: <7i05aq$rgl$1@news.orbitworld.net> <7i17gj$1u1k@news2.newsguy.com> <7icgkg$k4q$1@nnrp1.deja.com> <3749E9EC.2842436A@aasaa.ofe.org> <7id2eo$fag@drn.newsguy.com> <3749FF7D.F17CE16A@aasaa.ofe.org> <374AC676.F7AE0772@lmco.com> <7ieuja$5v9@news1.newsguy.com> Organization: ImagiNet Communications, Ltd. User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2) Newsgroups: comp.lang.ada Date: 1999-05-25T00:00:00+00:00 List-Id: I'm combining responses to two messages here. Hyman Rosen wrote: >Samuel Mize 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 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