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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b0d569080889afd6 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: A question for my personal knowledge. Date: 1999/05/18 Message-ID: <7hqcni$p8r@sjx-ixn1.ix.netcom.com>#1/1 X-Deja-AN: 479235011 References: <1VEZ2.1515$I51.88140@carnaval.risq.qc.ca> <37372A84.641F2133@bigfoot.com> <7h8oe8$2js$1@cf01.edf.fr> <37382B0C.A95B6745@bigfoot.com> <7h9o21$9v4$1@nnrp1.deja.com> <7h9pei$aut$1@nnrp1.deja.com> <373AC668.4824FF07@decada.enet.dec.com> <7hfctj$1kb4@drn.newsguy.com> Organization: Netcom X-NETCOM-Date: Mon May 17 5:37:06 PM PDT 1999 Newsgroups: comp.lang.ada Date: 1999-05-17T17:37:06-07:00 List-Id: In article <7hfctj$1kb4@drn.newsguy.com>, Mike wrote: >Ada OO mechanism is not simple and I find it confusing. a class is the >most basic concept in OO, and Ada does not have it. No wonder all heavely >used OO languages today use the class concept (C++, Java) even Simula >the original OO language used a class to represent objects with. All except >Ada does it different. ... and Oberon, and Modula-3. I believe it was Albert Einstein who said, "Everything should be as simple as possible but not simpler." The most basic concept in OO is not that of "class." Rather, it is the concept of "object." Not all OOPL's require "class" in the same form. Also, some practitioners make a distinction between type and class. In one of the languages cited, C++, the model is, type = class = module where the relationship is associative so we can also have, module = class = type class = type = module This relationship has definite advantages for some approaches to software development. Its simplicity also has its drawbacks. In fact, its very simplicity is seductive, especially in C++, where the model requires some rather bizzare code to compensate for the absence of other supporting constructs. For example, a properly designed C++ class requires at least one constructor, a copy constructor, overloading of assignment, and a destructor. And that is before one even gets started thinking about the problem to be solved. As one explores this presumably "simple" model in depth, it becomes clear that it is not at all as simple as we might have thought it would be when looking at the general form of the class construct. Ada has a model closer to, module contains type, type = root of derivation class class = a derivation of types A superficial examination of these two forms would lead one to conclude that C++ is simpler. That is a problem with superficial examinations. It is also the origin of an interesting paradox when comparing C++ and Ada in more depth. The Ada model has its advantages. We also admit to it having its own downside. Some OO practitioners regard the Ada model as "counter intuitive." It is only counter-intuitive if you are trying to make Ada look like the C++ or Eiffel model. Otherwise, it is, in practice, easier to design and implement code using the Ada model than with the C++ model. The superficially simpler model of C++ increases the implementation complexity during the source code development process. The Ada model of enclosing the type as root of a derivation class in a package seems, at first, more complex. This is the paradox. Even though Ada seems more complex because of the separation of concerns between module and type, it becomes simpler in practice. This paradox is not easy to see unless one has actually engaged in the development of software in both languages. Sadly, too many software managers see only the surface issues, and are misled into believing C++ is simpler because it seems to be so when looking at the basic form. When comparing Ada and C++, it is appropriate to keep the quotation from Einstein in mind, especially when doing a cursory evaluation of the two language design models. Richard Riehle richard@adaworks.com http://www.adaworks.com