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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,bf2f30a0886f0d6c,start X-Google-Attributes: gidf891f,public X-Google-Thread: 103376,bf2f30a0886f0d6c,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-22 03:46:14 PST Xref: sparky comp.lang.ada:4755 comp.lang.misc:4462 Path: sparky!uunet!pipex!bnr.co.uk!zaphod.axion.bt.co.uk!marble.uknet.ac.uk!uknet!mucs!clerew!chl From: chl@clw.cs.man.ac.uk (Charles Lindsey) Newsgroups: comp.lang.ada,comp.lang.misc Subject: Classes vs Tagged Types - Terminology Keywords: classes modules packages inheritance tagged types Message-ID: Date: 22 Mar 93 11:46:14 GMT Date: 1993-03-22T11:46:14+00:00 List-Id: There has been much heated debate on comp.lang.ada concerning the "tagged types" proposed for Ada 9x, and whether they shouldn't have been "classes" for greater similarity with C++. I think the case has been well made out that the tagged types in Ada 9x were the right approach technically, given the need to maintain the look and feel of Ada 83. However, there is a need to decide on the correct terminology (few seem to like the term "tagged") and, since a given term should hopefully describe approximately the same concept in all languages where it applies, I have widened the discussion to comp.lang.misc so that the non-Ada world can have its say. Here is what I have been teaching my students, by way of a taxonomy of modularised programming. Note in particular the meaning I give to various terms, so as to arrive at a (sort of) hierarchy of systems. I offer this as an Aunt Sally to be shot at - I think it important that some consensus should arise, and although Usenet discussions do not usually lead to consensus we might at least find out what the options are. MODULE A syntactic device for encapsulating groups of related declarations, usually procedures, and usually with some means to limit the exported identifiers so as to abstract away from implementation details. MODULES come in two flavours: PACKAGES CLASSES PACKAGE A MODULE of which only one instance exists (a static module, if you like). Things declared in the PACKAGE may be Operations (procedures or functions) Constants Variables Types possibly Other Packages If the variables are not exported (but can only be initialized or manipulated by exported operations), then we have an "ABSTRACT DATA OBJECT". For example, I may write a PACKAGE "Stack" with hidden implementation. This gives me just one stack. Examples: Packages in Ada Modules in Modula-2 However, if I choose to declare and export one or more Types, but with hidden internals so that only the exported operations can manipulate them, then I have an "ABSTRACT DATA TYPE". For example, in a PACKAGE "Stacks" I may export a Type "Stack", enabling clients to create as many independent stacks as they wish. And I can encapsulate several related types together and have operations that operate on, or know about, all of them. CLASS A MODULE of which many instances may exist, as created by an explicit "INVOCATION" (a dynamic module, if you like). Things declared in the CLASS may be Operations (procedures or functions) Constants Variables Possibly other Classes A CLASS is an elaborate kind of Type; INVOCATION typically occurs in a variable declaration, or by an explicit creation operation (often called 'new'). If the variables are not exported (but can only be initialized or manipulated by exported operations), then we have an "ABSTRACT DATA TYPE". For example, I may write a CLASS "Stack" with hidden implementation, enabling clients to create as many independent stacks as they wish. Note that I cannot create a single ABSTRACT DATE OBJECT using CLASSes (i.e. I cannot prevent a client from creating multiple instances). And I cannot encapsulate several CLASSes together or declare operations that operate on, or know about, several of them (except by declaring "friends" as in C++ - not a very elegant solution IMHO). CLASSes come in two flavours: Without INHERITANCE With INHERITANCE CLASS Without INHERITANCE Examples: Clusters in CLU Modules in Euclid CLASS With INHERITANCE Examples: Classes in Simula 67 Classes in C++ Classes in Smalltalk Classes in Eiffel It is generally agreed that you need INHERITANCE to do any serious "Object Oriented Programming". It is also common to refer to the Operations as "Messages" in some systems. CLASSes With INHERITANCE come in two flavours: SINGLE INHERITANCE MULTIPLE INHERITANCE Eiffel is a good example of a language with MULTIPLE INHERITANCE. To provide a counterpart to inheritance in PACKAGE-based systems, Types also come in two flavours: TYPES Without INHERITANCE TYPES With INHERITANCE TYPE Without INHERITANCE These are the Types you have known and loved in just about every programming language invented in the last 25 years. TYPE With INHERITANCE Example: Tagged Types in Ada 9x These are to enable "Object Oriented Programming" in PACKAGE-based languages. The concept seems good, and the (possible) advantages of PACKAGE-based systems over CLASS-based systems are retained. The term "Tagged Type" is used because values of such Types need to carry a Tag around at runtime. However, some complain that implementation details should not carry over into the syntax of High Level Languages, so maybe some other term is needed. I offer "Classified Type" for your consideration. Conclusion ---------- I have offered the following concepts: A. MODULE B. PACKAGE C. TYPE Without INHERITANCE D. TYPE With INHERITANCE E. CLASS F. CLASS Without INHERITANCE G. CLASS With INHERITANCE I believe all these concepts are useful and necessary. Whether I have matched the right term with each concept may be open to disagreement. In particular, some will want to use the term CLASS for Concept G (but what term for Concept E in that case?). There is also a need for a better term than "Tagged Type" for Concept D. -- Charles H. Lindsey ------------------------------------------------------------- At Home, doing my own thing. Internet: chl@clw.cs.man.ac.uk Voice: +44 61 437 4506 Janet: chl@uk.ac.man.cs.clw Snail: 5 Clerewood Ave., CHEADLE, SK8 3JU, U.K. UUCP: mucs!clerew!chl