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/20 Message-ID: <7i17gj$1u1k@news2.newsguy.com> X-Deja-AN: 480160054 References: <7i05aq$rgl$1@news.orbitworld.net> Organization: ImagiNet Communications, Ltd. User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2) Newsgroups: comp.lang.ada Date: 1999-05-20T00:00:00+00:00 List-Id: Original post rearranged a little. Shawn M. Root wrote: > ... some people were saying > that the Ada OO mechanism was counterintuitive. I tend to agree. ... >Perhaps I've missed > the point, but it seems like a Class construct would fit in well with > the Ada way of doing things. It seems like a logical evolution from a > package, to a generic package, to a class. First off, the class construct is used in other popular languages, so your argument is not without merit. It would be familiar, and its existence would ease the transition from those other languages. However, Ada already had some of the features that were added to other languages by object-oriented extensions. (Not to name any names, but it's initial is "C".) For instance, the "class" in C++ is the construct for object-oriented programming. It's also the construct for encapsulation of related functions, user definition and extension of types, and templates. But, except for OO programming, all of these were ALREADY in Ada. So the designers of Ada 95 were faced with a dilemma: should they introduce a familiar-looking set of "OO" features that duplicate existing features of the language, or should they introduce only the new features needed to make Ada 83 completely OO-capable, when it was already almost an OOP language to start with? For fair or foul, they took the second path. I personally think it was the right technical decision, but it creates a PR difficulty because people think that the C++ way is the "right" OO way. In fact, it's ONE approach to OO technology -- neither the best nor the worst, but certainly the most popular at present. I feel that the Ada 95 team made the right technical decision because it kept the language features more orthogonal -- that is, we didn't wind up with a bunch of different features doing the same thing. Also, as you stray from the strict C++ model, you find that it's much easier to define your abstractions clearly in Ada. For instance, you don't need a "friends" capability, because encapsulation is not provided by object classes. There are two areas where I've seen strongly-held objections to the Ada model: 1. There isn't a "class" construct that encloses the definition of a class. First note that in Ada terms, we aren't talking about a class, but about a type. A C++ "class" defines a template for data storage, and a set of operations on instances of that template. In Ada, this is a type. In Ada terminology, a "class" is a family of types. That's why a "class-wide" parameter can accept a value of a given type OR any of its descendants: that's an Ada "class." In C++ terms, it can accept a value of a given class or any subclass of that class. Anyway, in Ada, if you want to encapsulate the type definition with its primitive operations, you put a package around it. It just doesn't use the word "class," but it achieves exactly the same thing as a C++ class definition. The advantage to the Ada approach appears when classes are tightly coupled. The standard example is an OO type and an active iterator over that type. The iterator needs to see the "innards" of the other type. In C++ you have to define the iterator class as a "friend" of the other class. In Ada you can simply encapsulate both types in the same package, or with the iterator as a child package. 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. I personally think it would be useful to define some pragma or comment-flag tags that will encode, in the code, what design approach is being used. Some things could be checked for you that are not currently checked, and an ASIS-based tool could look through the compiled results, find what design approach was intended for a given chunk of code, and check those specific constraints. Other people have reacted violently against this idea, for reasons I did not find clear. It seemed they were arguing that not all code should conform to the C++ model, and I certainly agree. I do think it would be useful to encode whether or not a given tagged type was designed to that model, or to another model, and that the compiler suite could check it against the constraints of whatever model it was designed against. But anyway, my overall point is that encapsulation of a type with its primitive operations (in C++ terms, a class) is done with the encapsulation operator in Ada, which is the package. A C++-style "class" would be a redundant encapsulation operator. 2. You can't use "object.method" notation. This is another case where the Ada design gives less support to one specific view of OO technology, because it's supporting more views of OO technology. Specifically, the C++ model is that one object "receives a message" and operates on it, and this is modeled with a function call. The Ada model is, loosely, that a function call identifies an action to occur (or a message, if you prefer), a set of related information (the non-controlling parameters), and a set of objects. These objects, all of the same class, cooperate somehow to accomplish the action (or respond to the message). So, if you want to design using a specific "recipient" for each "message," you can do so. One common approach for this is to use the first parameter for the "recipient." You don't get to call out the recipient as part of the syntax, but on the other hand you don't have to arbitrarily pick one "recipient" if you aren't using that model of object interaction. > This > concern was dismissed by others as being merely "syntactic sugar", and > claims were made that the Ada mechanism is actually easier to use than > the C++ style. These arguments seemed misplaced to me. I thought that > one of the goals of Ada was to focus on the reader of the code, not the > writer. Therefore if this "syntactic sugar" makes code easier to > understand, then it would be a good thing, right? I hope I've clarified the point that, in some cases, the syntax you are talking about would become LESS clear, not clearer. The argument is really whether the language should specifically support one model of OO technology, to the detriment of other models, simply because the currently-most-popular OO language uses that model. > The syntax would even be > similar since (at least where I work) use clauses are rarely used. > We write > Package_Name.Procedure; > so what's wrong with > Class_Name.Method; Nothing. In fact, you can do that now with a one-class-per-package approach, and I don't think you can do it in C++. I note that people who want "object.method" notation often refer to it as "class.method" notation. This suggests to me that their objection is not based in the structure or meaning of the facility, but is about the code having an unfamiliar "look," because they so often mis-state the structure and meaning of what they're requesting. This isn't meant as a dig at you. Rather, I'm pointing out that this issue really seems to be that Ada has a different "look and feel" than C++ or Smalltalk. Adding a "class" encapsulator and "object.method" notation certainly won't change that! Trying to write Ada code that conforms to a C++ view of syntax and semantics is as foolish as trying to write C++ code to look like Ada. To some extent, if you could just uproot notations from one language and plop them down in the other, there'd be no reason to have both languages. I feel that both C++ and Ada have real value. I feel it's good to have BOTH languages -- our understanding of the deeper issues is greatly enhanced by having more than one way to express them. Philosophy final exam: "Describe human thought. Compare and contrast with any other kind of thought." > Maybe I just don't understand the issues. I would appreciate any help > in making this clear. I hope you found this helpful. > Shawn M. Root Sam Mize -- Samuel Mize -- smize@imagin.net (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam