From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 30 Jul 93 22:07:29 GMT From: agate!howland.reston.ans.net!noc.near.net!inmet!spock!stt@ucbvax.Berkeley .EDU (Tucker Taft) Subject: Re: What is supported by Ada ? Message-ID: List-Id: In article <235khi$bcn@risc1.rz.fh-heilbronn.de> hacki@sun1.rz.fh-heilbronn.de writes: >I was asked to give an overview concerning the object-oriented features suppor ted by the various programming languages. > >Therefore I would be very glad if somebody mailed me the answers to the follow ing questions. > >Does Ada support I will presume you mean Ada 9X. >- classes and objects Yes. The term "class" refers to a set of types organized in a hierarchy; a subclass is a subset of types. Each class is "rooted" at some type, and consists of that type and all of its derivatives, direct and indirect. There are also "class-wide" types which can be used as the type of a formal parameter (or the target type of a pointer type) when objects of any type in the class are acceptable as actual parameters (or as targets of pointers). Given an operand of a class-wide type, it can be passed as a parameter to any of the primitive operations (aka "virtual functions"/"methods"/"dispatching operations") of the corresponding "specific" type, and an automatic run-time dispatch takes place to the "appropriate" implementation of the operation. In other words, class-wide types provide for run-time polymorhism. To preserve performance, only types marked as "tagged" support type extension and class-wide programming. All instances of such a type include a run-time type identifier (a "tag" -- hence the name), to enable run-time dispatch (aka dynamic binding), as well as explicit class membership testing. As in Ada 83, untagged types support type derivation (without extension), and classes of such types are still defined, but only "compile-time" polymorphism is provided for them as part of generic instantation (using so-called "formal derived types"). >- abstract classes Yes. These are called "abstract types." Any tagged type with one or more "abstract" primitive operations is an abstract type. No instances of such types are permitted, but they may be used as the parent for deriving concrete (or abstract) derivative types. >- messages / methods Yes, as mentioned above, the "primitive operations" of a tagged type will automatically "dispatch" when passed an operand of a class-wide type. >- static binding when possible Yes, when the actual parameters in a call are of a specific type, as opposed to a class-wide type, static binding is used. A given object can be explicitly "viewed" as either of a specific type or of a class-wide type by using explicit conversion, so the programmer has complete control. Renaming may be used to create and then give a name to a particular "view" of an object. The view can be class-wide, or can be of any specific type that is an ancestor of the "underlying" type of the object (including the underlying type itself, of course). Hence, the combination of explicit (view) conversion and renaming allows a programmer to view an object as any appropriate specific type, and to easily pass the object to any ancestor's operation that is useful in the implementation of some given operation. Finally, it is of course legal for the compiler optimizer to "notice" cases where it "knows" the tag of the controlling operand(s), and therefore can statically bind the call to the corresponding implementation. Even without this optimization, dynamic binding is quite efficient, since a simple level of indirection is all that is necessary to do the run-time dispatching (no "method searching" at run-time is necessary because of the compile-time type checking). Hence, one chooses static binding not because it is significantly more efficient, but rather because, semantically, you don't want to (re)dispatch, but instead want to execute a particular implementation of a given operation. In other words, the decision between static and dynamic binding is analogous to the decision between sending a SmallTalk message to "super" versus "self." >- automatic garbage collection. This is an optional feature. Ada 9X compilers may support garbage collection, but need not. On the other hand, support for user-defined "finalization" (aka destructors) is required. Therefore, a programmer may ensure that when an object goes out of scope, any storage pointed-to by the object can be reclaimed. Furthermore, Ada 9X, like C++, has "value-based" rather than "reference-based" declaration and assignment semantics. Therefore, stack allocation is used for normal local variables (including variables of a "tagged" type), and hence automatic stack deallocation is provided. Explicit pointers are permitted, with explicit (heap) allocators and explicit deallocation (essentially equivalent to C's malloc and free, or C++'s new and delete). As mentioned above, one can automatically perform the deallocation of pointed-to storage when an object (a "controlled" object) containing a pointer goes out of scope. Alternatively, reference-counting schemes may be implemented, or whatever appropriate storage management approach that is desired. >Thanks in advance My pleasure. >Hacki S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138