ian@loral.UUCP (Ian Kaplan) (01/25/85)
In article <366@cavell.UUCP> brian@cavell.UUCP (Brian Wilkerson) writes: > >I therefore propose that the original definition be revised to read : > >object-oriented, adj., 1. wholly or largely concerned with the definition > and use of abstract data types. 2. consisting wholly or largely of > abstract data types. > >Brian Wilkerson > ...!ihnp4!alberta!brian 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. A Modula definition module defining such a stack "object" is shown below. The actual stack data structure is hidden inside the module. It can only be manipulated by the two procedures Push and Pop. DEFINITION MODULE StackOps; FROM ExpTypes IMPORT Operators; EXPORT QUALIFIED Push, Pop; PROCEDURE Push( Value : REAL ); PROCEDURE Pop() : REAL; END StackOps. In Modula there would also be a separately compiled implementation module which would implement the data structure and the procedures Push and Pop. This module is not important for this discussion. 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++. These languages support abstract data types. To add this facility to Modula, one would have to be able to declare a variable whose type was the object. For example: VAR MyStack : StackOps. Operations on the object would be performed in the following way Value := MyStack.Pop; and MyStack.Push( Value ); In this case the operations are explicitly associated with the data type, it is not a loose associate as is the case with a Modula module. Concurrant Pascal uses a scheme similar to the one I have outlined[2]. This is a rather long winded way of stating that I agree with Brian Wilkerson's definition of an object oriented language. An object oriented language provides an abstract data type which embodies both the data and the operations which can be performed on the data. Although there are clearly similarities between this and the facilities provided by Modula and Ada, these languages are not truly object oriented languages. [1] "Software Engineering With Modula-2 and Ada" by Wiener and Sincovec, John Wiley and Sons, 1984 [2] "The Architecture of Concurrent Programs" by Per Brinch Hansen, Prentice-Hall, 1977 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@cheviot.UUCP (Robert Stroud) (01/31/85)
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... "
ian@loral.UUCP (Ian Kaplan) (02/04/85)
In article <247@cheviot.UUCP> robert@cheviot.UUCP (Robert Stroud) writes: > >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. > ... more discussion regarding packaging in Ada etc.... >Is it possible to focus on that difference and produce >a definition of "object-oriented" that *excludes* Modula-2?? > >Robert Stroud, >Computing Laboratory, >University of Newcastle upon Tyne. > >ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa >UUCP ...!ukc!cheviot!robert > The point that I was trying to make in my Concurrent Pascal example was that there should be a strong association between the data structure and the operations that can be perfored on it. I think that Robert Stroud is probably right when he states that the differences between my Concurrent Pascal example and the way the same thing is done in Modula is syntatic sugar. After I wrote my article several other people pointed out that the real difference between Modula (or Ada) and an object oriented language like Smalltalk or C++ is inheritance. Inheritance allows new abstract data types to be formed from the "properties" of other abstract data types. In a way, inheritance does for abstract data types what user defined data types does for elementary data types in Modula. When discussion the differences between a "truely" object oriented language and Modula with a friend, my friend pointed out that you must make a distinction between what you can simulate in a language and the properties of the language. For example, a programmer can simulate recursion in FORTRAN by using an array like a stack, but recursion is not one of the features of FORTRAN. There is clearly some overlap between the object oriented languages and Modula or Ada. Despite this overlap, they really are different languages. I think that the problems we are all having in defining the differences between object oreinted languages and Modula is that until recently (when the mini-Smalltalk implementation became available) object oriented languages were not generally available. I believe that if we were to use object oriented languages, rather than just read about them, the difference would be much more apparent. By the way, from what I understand AT&T has no plans to release C++. If this is true, I think that it is a real loss to the computer science community. Ian Kaplan Loral Data Flow Group Loral Instrumentation (619) 560-5888 x4812 USENET: {ucbvax,ihnp4}!sdcsvax!sdcc6!loral!ian ARPA: sdcc6!loral!ian@UCSD USPS: 8401 Aero Dr. San Diego, CA 92123
jih@usl.UUCP (Juha I. Heinanen) (02/05/85)
I agree with Robert Stroud that from the programmer's point of view it
was a serious mistake to include the privite part in the package
specification and thus force the programmer to tell the memory
representation of a private type before writing the package body. Since
the algorithms depend on memory representation and vice versa it is in
practice impossible to separate the specification from the
implementation. This ruins the whole idea of data abstraction with
separate compilation.
What comes to Modula-2, I wouldn't have placed any restrictions on the
memory representation of opaque types. If the actual representation
turns out to fit in one word then that is fine. If not I would have
made the compiler implicitly declare a pointer variable that points to
the real memory representation and implicitly allocate the object from
the heap. Similarly all direct references to the memory representation
would have been implicitly changed to pointer references. This
arrangement would have freed the programmer from the artificial
introduction of pointer variables.
Juha Heinanen
USL, P.O. Box 44330, Lafayette, LA 70504, tel. (318)231-5345
UUCP: {ut-sally, akgua}!usl!jih ARPA: usl!jih@ut-sally
--
Will this be appended?arnold@gatech.UUCP (Arnold Robbins) (02/07/85)
In article <777@loral.UUCP> ian@loral.UUCP (Ian Kaplan) writes > By the way, from what I understand AT&T has no plans to release C++. If > this is true, I think that it is a real loss to the computer science > community. This is getting off the topic a little bit, but I wanted to clear a point up. AT&T is releasing C++ *only* to educational licensees. The cost is $150 for the tape and another $20 for the printed documentation. I would love to see C++ released to everyone, but at least some people can get hold of it. The fact that they are releasing it at all encourages me to hope that eventually everyone will be able to get it. -- Arnold Robbins CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold Help advance the state of Computer Science: Nuke a PR1ME today!
dick@luth.UUCP (Dick O Schefstr|m) (02/11/85)
The not too fruitful discussion of whether Ada or Modula-2 is more "object-oriented" seems to turn into a discussion of implementation of "private" or "opaque" types. Maybe typical to Ada, it provides several ways of doing things: the Modula-2 style of private types is in Ada achieved by in the private part declaring an "access" type, allowing us to defer the layout of the structure pointed to until writing the implementation part. This give us a higher degree of independency between specification and implementation parts, but it also means that we cannot give default initializations to private types and an initialization routine must be explicitly called. If you create a lot of temporary used objects of this private type, using the "pointer style", you might have to start thinking about reuse of space and garbage collection. To statically allocate objects has drawbacks, but their space is easily and automatically reclaimed when no longer used by the simple procedure call-stack mechanism. Dick Schefstrom, Computer Science Department University of Lulea S-951 87 Lulea Sweden