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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site cheviot.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!mcvax!ukc!cheviot!robert From: robert@cheviot.UUCP (Robert Stroud) Newsgroups: net.lang.st80,net.lang.ada,net.lang.mod2 Subject: Re: Definition of Buzzwords: "Object-Oriented" Message-ID: <247@cheviot.UUCP> Date: Thu, 31-Jan-85 15:10:41 EST Article-I.D.: cheviot.247 Posted: Thu Jan 31 15:10:41 1985 Date-Received: Sun, 3-Feb-85 09:51:53 EST References: <4288@ucbvax.ARPA> <366@cavell.UUCP> <769@loral.UUCP> Reply-To: robert@cheviot.UUCP (Robert Stroud) Distribution: net Organization: U. of Newcastle upon Tyne, U.K. Xref: watmath net.lang.st80:174 net.lang.ada:176 net.lang.mod2:152 Summary: List-Id: In article <769@loral.UUCP> ian@loral.UUCP (Ian Kaplan) writes: > > Several books have come out which suggest that languages like Ada and > Modula-2 are "object oriented" languages[1]. These languages are object > oriented in that a module (or package) can be defined which contains a > data structure and the operations which can be performed on the data > structure. > > ... example of MODULE containing a STACK abstraction > > There is a real difference between the type of "object" which can be > created using Modula's modules and the objects in a language like > Smalltalk or C++. > > .... discussion of how one *might* declare ADT's in Modula-2 > But it *is* possible to define abstract types in Modula-2, (or Ada - hiss!). Modula-2 lets you export a TYPE name without defining the TYPE structure - this is called "opaque export" and is discussed under "14. Compilation Units" in my version of the Modula-2 Report. You can then declare variables of this type, but the only way you can use them is as parameters to procedures or functions exported by the MODULE which defines the TYPE - where the internal structure is known. So if we have a MODULE StackDef which EXPORT's the TYPE Stack and procedures Push and Pop, we can write.... FROM StackDef IMPORT Stack, Push, Pop; VAR S : Stack; BEGIN ... Push(S, ...); Pop(S, ...); ... END; You even have to call an exported procedure (not shown) to initialise the Stack before you use it - unlike Ada, Modula-2 does not allow initialisation at declaration. This is *not* the same as Concurrent Pascal notation, S.Push(...); S.Pop(...); but the difference is really just philosophical - does the operation belong to the object or vice-versa. Some would say that this makes a language "object-oriented" rather than "procedure-oriented" although the distinction is purely syntactic sugar. In "Chapter 25 Program decomposition into modules" of Wirth's book on Modula-2, he says that MODULE's come in three flavours. They can map between two data types, encapsulate a single data type or implement a data type in the way I have described. The MODULE's in Modula-2 have more to do with visibility, lifetime and scope than data types. The corresponding mechanism in Ada is type Stack is private; However, there is one (to my mind) crucial difference. In Modula-2 there is *nothing* about the TYPE definition in the DEFINITION MODULE *anywhere*. However, since the compiler must be able to allocate space for an opaque object, the size is fixed, (specifically the TYPE must be a POINTER or a subrange of a standard type, i.e. one "word"). In practice, this is not a problem - the "real" type is a massive RECORD, and the opaque type is a pointer to the RECORD; the create operation allocates space for the object and initialises its value. In Ada however, (flame flame), the package interface (to use Ada terminology) contains a private part which spells out the type definition and initial value as appropriate. This means that the compiler knows the information even it denies the knowledge to the programmer. So what you ask? Well, consider what happens when you decide you want to change the internal representation of your abstract type. In Modula-2 you just have to compile the IMPLEMENTATION part of the module; in Ada you have to re-compile the interface. That means you have to re-compile *everything* that uses that interface (and some other interfaces may use the interface...). Anyone who has had experience of writing large programs in languages with strong-type checking across compilation boundaries (e.g. Modula-2 or Mesa) will tell you that re-compiling interfaces is *bad* news!! Personally, I wonder if a clever linker could solve this problem, lifting the restriction in Modula-2 and banishing the private part of the interface from Ada. However, in the meantime I prefer the Modula-2 solution. An object-oriented language like Smalltalk or C++ (I guess), gets round this difficulty by allocating all objects off the heap dynamically at run-time, and referring to everything indirectly with pointers. Smalltalk even goes as far as to do all its type checking and binding of operations to implementations at run-time, which adds a substantial run-time overhead. On the other hand, it makes the conventional compile/link cycle unnecessary, making it very fast to prototype applications. Although you can program Abstract Data Types in both Modula-2 and Smalltalk (making them both "object-oriented"??), there is a big difference between the two languages. Is it possible to focus on that difference and produce a definition of "object-oriented" that *excludes* Modula-2?? > Ian Kaplan > Loral Data Flow Group > Loral Instrumentation > USENET: {ucbvax,ihnp4}!sdcsvax!sdcc6!loral!ian > ARPA: sdcc6!loral!ian@UCSD > USPS: 8401 Aero Dr., San Diego, CA 92123 > (619) 560-5888 x4812 Robert Stroud, Computing Laboratory, University of Newcastle upon Tyne. ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa UUCP ...!ukc!cheviot!robert "... you can solve any problem in Computer Science by adding an extra level of indirection... "