wildbill@ucbvax.ARPA (William J. Laubenheimer) (01/22/85)
I have recently been involved in some discussions in which the topic
of so-called "object-oriented" languages and programming techniques
has been explored. Despite the fact that "everybody knows" that
Smalltalk-80 is "object-oriented" and "everybody knows" (or pretends
that they do) what "object-oriented programming" is, this same
group of "everybody"s is having a hard time coming up with a rigorous
definition of those terms which goes beyond one of the two following:
1) The term is self-explanatory: the orientation of the language/program
is towards the "object". This causes the discussion to move in
the direction of defining an "object", and how exactly the language
or program is oriented in that direction.
2) The term is defined by example: if somebody says a language is "object-
oriented" and most people agree, then the language is object-oriented
(the "science fiction" definition approach - "science fiction" is what
"science fiction authors" write, "science fiction editors" buy, and
"science fiction fans" read).
Neither of these approaches makes anybody particularly happy. Nobody's
been able to find an accepted definition in the literature, either.
So, the question is:
Is there a definition of the term "object-oriented" which is both descriptive
of all current uses of that term and accepted by all who currently use it?
If not, can such a definition be constructed?
I would be interested in hearing from anybody who has any ideas relating
to this topic.
Bill Laubenheimer
----------------------------------------UC-Berkeley Computer Science
...Killjoy went that-a-way---> ucbvax!wildbillmacrakis@harvard.ARPA (Stavros Macrakis) (01/23/85)
> Is there a definition of the term "object-oriented" which is both descriptive > of all current uses of that term and accepted by all who currently use it? > Bill Laubenheimer ucbvax!wildbill `Accepted by all who currently use it' is harder than `descriptive'.... Let me propose: An object-oriented language/system considers its behavior to be defined in terms of the behavior of smaller units (called `objects') each of which has a repertoire of operations applicable to it. The object operations are the only operations which normally have access to the underlying implementation of the object. Almost all object-oriented systems organize objects into classes of different individual objects which share the same repertoire of operations, and these classes can normally have subclasses which inherit the operations of the classes and add more classes. Almost all object-oriented systems allow (and encourage) objects to have internal state which changes with time. This definition emphasizes the differences with other language qualities, such as `algorithmic' (Algol, Fortran, Pascal, C, Snobol, APL), `functional' (Lisp, FP, APL), `backtracking' (Snobol, Planner, Prolog), or `string-oriented' (Snobol, Trac, Teco); but note that the qualities are not exclusive. Too often, spurious questions on the order of `is it algorithmic or is it object-oriented' cloud the question. A serious question, however, is whether changing state is important to object orientation. Perhaps this is the difference between data abstraction and object orientation? Or is object orientation just the fashionable name for data abstraction? A more historically-oriented definition might be: Object-oriented languages/systems are inspired by Simula 67. Note that it is not important to these definitions whether the language is part of an interpretive system (like Smalltalk), nor is the inheritance mechanism central (of course you can argue that a GOOD object-oriented system has a certain kind of inheritance mechanism). By these definitions, Simula 67, CLU, Smalltalk, Objective C, Ada, and ZetaLisp are all object oriented. They do differ. Some enforce the access restrictions of the class, others don't; some have sophisticated (or just plain complicated) inheritance mechanisms, others don't. But I think it would be unfair to frame a definition which excluded any of these languages. -s
brian@cavell.UUCP (Brian Wilkerson) (01/23/85)
> Is there a definition of the term "object-oriented" which is both descriptive > of all current uses of that term and accepted by all who currently use it? > If not, can such a definition be constructed? I don't know of any "standard" definition for the term "object-oriented", but I will attempt to construct one. Whether or not it will be widely accepted is something we should find out when people start replying to this article. One alternative you suggested was the following. > 1) The term is self-explanatory: the orientation of the language/program > is towards the "object". This causes the discussion to move in > the direction of defining an "object", and how exactly the language > or program is oriented in that direction. I define "object" as follows : object, n., 1. a member of an abstract data type. This definition undoubtedly stems from my familiarity with Smalltalk-80. (The correspondence between abstract data types and classes is relatively clear.) It does, however, seem to be consistent with other uses of the word which I have seen. This leaves only the problem of how the language, program or programming methodology is oriented towards the object. It seems to me that people, when they say that Smalltalk is object-oriented, mean that Smalltalk is a language in which everything is an object. This may be a bit too restrictive to be useful, though. 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
jjm@petsd.UUCP (Jim Moseman) (01/23/85)
I use "object-oriented" to describe a design strategy with the following characteristics: 1. The programs's objective is described in terms of one or more higher level entities (objects). For example, an algorithm involving a depth first search of a tree is easier to describe in terms of a stack and its push and pop operations than in terms of lower level entities such as arrays and indices. 2. The implementation of the object and its operations (its representation and the algorithms which manipulate it) is isolated from the implementation of other objects and from the algorithms which use the object. This allows a 'divide and conquer' approach and simplifies maintenance by limiting the effect of changes. Jim Moseman @ Perkin-Elmer, Tinton Falls, N.J. .../vax135/petsd/jjm
jans@mako.UUCP (Jan Steinman) (01/23/85)
<4288@ucbvax.ARPA> wildbill@ucbvax.ARPA (William J. Laubenheimer) writes: >I have recently been involved in some discussions in which the topic >of so-called "object-oriented" languages and programming techniques >has been explored... (we are) having a hard time coming up with a rigorous >definition of those terms... > >1) The term is self-explanatory: the orientation of the language/program > is towards the "object". This causes the discussion to move in > the direction of defining an "object", and how exactly the language > or program is oriented in that direction. I essentially agree with this argument, but see no problem providing a rigorous definition of an "object", which is, most generally, a cohesive collection of data and allowed operations on that data. Within an object data-function binding is high, while between objects, a loose coupling mechanism is used to protect the integrity of those objects. "An object consists of some private memory and a set of operations... Objects representing numbers compute arithmetic functions. Objects representing data structures store and retrieve information." [1:p6] The crucial point is the collection of data AND functionality. Traditional languages keep the two apart and allow functionality to operate ON data. Object oriented languages have objects knowledgeable in the kinds of things they may do to their data -- these objects honor requests from other objects to do these things. The net effect is one of greater modularity, reliability, (because an object will not permit its data to be corrupted by inappropriate operations) and generally better understandability, due to the intuitive face objects present. "...modules may be functional (procedure-oriented) or declaritive (object- oriented)... we want modules that exihibit strong cohesion..." [2:p29] "A crucial property of an object is that its private memory can be manipulated only by its own operations." [1:p6] The second major indicator of "objectness" is the degree of modularity. Some try to argue that "C" is modular, simply because functions and data can be seperately compiled, but the language does not enforce any sort of binding within such modules! True objects will have tight binding, or cohesion, within a module, and loose coupling between other modules. This binding must extend to the binding between data and functionality, as stated in my first point. To sum up this too long answer: "We shall call this an *object-oriented* design methodology to emphasize the fact that it is not a purely functional design technique. Instead, this approach recognizes the importance of software objects as actors, each with its own set of applicable operations." [2:p40] References: [1] "Smalltalk-80, The Language and its Implementation", Adele Goldberg, David Robson [2] "Software Engineering With Ada", Grady Booch (excellent book!) -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
jeh@ritcv.UUCP (Jim Heliotis) (01/23/85)
> Is there a definition of the term "object-oriented" which is both descriptive > of all current uses of that term and accepted by all who currently use it? > If not, can such a definition be constructed? > > Bill Laubenheimer If you would like to test every language for object-orientedness, and answer 'yes' or 'no', then I'd say that is the wrong approach. I would rather say things like (1) Pascal is not very object-oriented, (2) Ada is rather o-o, and (3) Smalltalk-80 is very o-o, because even booleans are defined as ST80 objects. I realize I am not offering a definition. I just want to point out that I think it is a matter of degree. Jim Heliotis {allegra,seismo}!rochester!ritcv!jeh rocksvax!ritcv!jeh ritcv!jeh@Rochester
ekrell@ucla-cs.UUCP (01/24/85)
In article <4288@ucbvax.ARPA> wildbill@ucbvax.ARPA (William J. Laubenheimer) writes: >Is there a definition of the term "object-oriented" which is both descriptive >of all current uses of that term and accepted by all who currently use it? >If not, can such a definition be constructed? > >I would be interested in hearing from anybody who has any ideas relating >to this topic. I read this somewhere: a procedure-oriented language represents the behavior of a program by describing the effect of applying procedures to different kinds of arguments (here procedures being a broad term including assignments, arithmetic operators, etc). An object-oriented language does it by describing the effect of applying different procedures (methods) to a specific object. I like this (informal) definition because it captures the radical difference between procedure and object-oriented languages. -- Eduardo Krell UCLA Computer Science Department ekrell@ucla-locus.arpa ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!ekrell
koved@tove.UUCP (Larry Koved) (01/25/85)
A rather good description of what it means to be "object-oriented"
was given in a paper by Curry and Ayers, entitled "Experience with
Traits in the Xerox Star Workstation", IEEE TSE, Sept 1984.
It is the best description that I have seen so far, although not
totally satisfactory.
Larry
--
Spoken: Larry Koved
Arpa: koved.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!kovedrobert@cheviot.UUCP (Robert Stroud) (01/25/85)
Bill Laubenheimer (wildbill@ucbvax.arpa) asks for a definition of
object-oriented programming.
I have always been fond of the following quotation...
"Object-oriented programming will be in the 1980's
what structured programming was in the 1970's.
Everyone will be in favour of it...
Every programmer will practice it (differently).
And no one will know just what it is!"
It comes from an article entitled "Object-Oriented Programming" by
Tim Rentsch which can be found in ACM SIGPLAN Notices, September 1982
on pages 51 to 57. The article goes on to try and characterise just
what object-oriented programming is all about, and I recommend you
look it up if you're interested.
Personally, I remain to be convinced that there is any fundamental
difference between objects/messages and abstract data types/operations,
but I guess that is just swapping one bit of jargon for another!
However, I do agree with previous correspondents that it is a matter
of degree rather than an absolute measure, although I would put more
weight on the importance of the class hierarchy, inheritance and
polymorphic aspects of an object-oriented programming language.
Robert Stroud,
Computing Laboratory,
University of Newcastle upon Tyne.
ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa
UUCP ...!ukc!cheviot!robert
"It ain't what you do, it's the way that you do it"glassner@unc.UUCP (Andrew S. Glassner) (01/25/85)
The posting on OO buzzwords asked for definitions of the term "object- oriented". To me, the words describe a point of view and a style of implementation. The point of view is that the procedure/data relationship is flipped over from that of most other languages, e.g. Algol, APL, Snobol, etc. Thus, instead of having a general procedure "cut" that accepts the two pieces of data "scissors" and "paper", we have an object "scissors" that is given "paper" and told to "cut". The meaningful thing for me in this view is that relationships between objects (data in the Algol view) are *implicit*, not explicit. If a balloon object is told that air is arriving at the hole, it will blow itself up. It doesn't need to know from where that air arrives, and the balloon does not need to be told in its code of all the different places from which air can arrive. The style of implementation of object-oriented code is that of self-contained, encapsulated "objects" (or collections of procedures, or "methods") that communicate with each other via "messages", or commands. This takes the popular notion of "hiding" important information or local data to a fully-implemented conclusion. Each object is responsible for its own local information (the data which describe it and the messages to which it can respond), and nobody else can touch that information. Other objects may ask to see it or ask to change it, but only the owner of the information has direct access to it. In my perception, the difficulty in defining the term object-oriented rests in a subtle point of view. In general, when one is learning of a new idea (or having a new idea defined), a major question is "Why am I being told this?" The usual expectation is that the new concepts or techniques are somehow *better* than other techniques, and indeed this is the usual reason people try to expose us to other ways of doing things. To compter-science people, "better" often means "more powerful", or "more expressive". Thus, APL is "better" than ALGOL because it can express complicated ideas in compact space, whereas ALGOL is "better" than APL because it is more readable. The problem is that the object-oriented point of view, when described statically, appears no more "powerful" than the traditional procedure/data model. Thus, why bother to spend the time and energy to learn it? I feel the justification comes from the point of view that the programming model we work with profoundly affects our work. This isn't a new idea; the example is often made that the spoken language you use affects the way you think and approach problems. So although the "object/method" view may not immediately seem more "powerful" than the "data/procudure" view, it is a different way to describe the work to be done. If the new point of view is as powerful as the old (which it is), and if it is truly a new point of view (which can be argued, but only after one understands it!), then that is justification in itself for its study. To my mind, the OO point of view is "better" because it lets me formulate my problems in terms of implicit relationships between intelligent data, rather than explicit manipulations of information. I suggest that the above may also serve as a defintion of "object-oriented". -- -Andrew Andrew Glassner decvax!mcnc!unc!glassner
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@gitpyr.UUCP (Robert Viduya) (01/27/85)
>< > I read this somewhere: a procedure-oriented language represents the > behavior of a program by describing the effect of applying procedures > to different kinds of arguments (here procedures being a broad term > including assignments, arithmetic operators, etc). > An object-oriented language does it by describing the effect of applying > different procedures (methods) to a specific object. > The definition is lacking two important things: the definition of 'arguments' and the definition of 'objects'. After all, an argument could, in some contexts be considered an object. robert -- Robert Viduya Office of Computing Services Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-4669 ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
trow@uw-june (Jay Trow) (01/27/85)
Forwarded from Smalltalk80Interest^.x@Xerox.arpa ---------------------------------------------------------------- Date: 23 Jan 85 08:58:44 PST (Wednesday) From: Cornish.SV Subject: Re: Definition of Buzzwords: "Object-Oriented" This is not going to be a "rigorous definition". First, let's realize, that to say a software system is "object oriented" really means that the architecture of a software system is "object oriented". Now just what does the term "architecture of a software system" really mean? Any software system has a purpose. The architecture of a software system must be devoted to achieving that purpose, just as the architecture of a building must be devoted to achieving the purpose of that building. Let's take a historical perspective: what was the first object-oriented system and what was it's purpose? I propose a candidate which will come as no surprise to anyone, SIMULA-67. Oh yes, SIMULA-67, the father of SMALLTALK. Oh yes, SIMULA-67, the frequently cited language in papers on abstract data types. Oh yes, SIMULA-67 the language cited as an inspiration to the designers of the Burroughs 6700 computer, the first computer with an operating system written in ALGOL. But just what was the purpose of SIMULA-67, contrasted with the purpose of ALGOL-60 on which it was based? SIMULA-67 was designed to for discrete-event simulation applications. ALGOL-60 was first devised to express mathematical algorithms. What is simulation and how is it different from a mathematical algorithm? Can we agree that a simulated world consists of "objects"? What are the characteristics of such objects, at least relative to the simulation? Each has a *lifetime* and each has *behavior*. Each object is "doing it's own thing" acquiring and releasing resources, even being a resource itself. Each object can be identified with a separate process. Comments? Jan Cornish ----------------------------------------------------------------
fairley@wanginst.UUCP (Dr. Richard Fairley) (01/29/85)
> I have recently been involved in some discussions in which the topic > of so-called "object-oriented" languages and programming techniques > has been explored. Despite the fact that "everybody knows" that > Smalltalk-80 is "object-oriented" and "everybody knows" (or pretends > that they do) what "object-oriented programming" is, this same > group of "everybody"s is having a hard time coming up with a rigorous > definition of those terms which goes beyond one of the two following: > > 1) The term is self-explanatory: the orientation of the language/program > is towards the "object". This causes the discussion to move in > the direction of defining an "object", and how exactly the language > or program is oriented in that direction. > > 2) The term is defined by example: if somebody says a language is "object- > oriented" and most people agree, then the language is object-oriented > (the "science fiction" definition approach - "science fiction" is what > "science fiction authors" write, "science fiction editors" buy, and > "science fiction fans" read). > > Neither of these approaches makes anybody particularly happy. Nobody's > been able to find an accepted definition in the literature, either. > So, the question is: > > Is there a definition of the term "object-oriented" which is both descriptive > of all current uses of that term and accepted by all who currently use it? > If not, can such a definition be constructed? > > I would be interested in hearing from anybody who has any ideas relating > to this topic. > > Bill Laubenheimer > ----------------------------------------UC-Berkeley Computer Science > ...Killjoy went that-a-way---> ucbvax!wildbill In my view, object-oriented means data abstraction PLUS inheritance and dynamic binding; although most data abstraction languages use strong type checking, which is inconsistent with dynamic binding. By data abstraction, I mean separation of specification from implementation, information hiding, and state retention within the object. The term object-oriented has been appropriated by different disciplines: database, architecture, operating systems, and programming languages all use the term with different meanings. The term is especially confused within the programming field because Grady Booch and the Ada crowd use the term for what most people refer to as data abstraction; i.e., information hiding with state retention and strong type checking. The easiest way to distinguish object-orientation from data abstraction is to say it's what Smalltalk does that Ada does not. I think you will find that the Smalltalk people at Xerox PARC have the historical edge on use of the term. Dick Fairley decvax!wanginst!fairley
ekrell@ucla-cs.UUCP (01/30/85)
> >< > > I read this somewhere: a procedure-oriented language represents the > > behavior of a program by describing the effect of applying procedures > > to different kinds of arguments (here procedures being a broad term > > including assignments, arithmetic operators, etc). > > An object-oriented language does it by describing the effect of applying > > different procedures (methods) to a specific object. > > > > The definition is lacking two important things: the definition of 'arguments' > and the definition of 'objects'. After all, an argument could, in some contexts > be considered an object. > > robert > -- > Robert Viduya > Office of Computing Services > Georgia Institute of Technology, Atlanta GA 30332 > Phone: (404) 894-4669 > > ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert > ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert *** REPLACE THIS LINE WITH YOUR MESSAGE *** -- Eduardo Krell UCLA Computer Science Department ekrell@ucla-locus.arpa ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!ekrell
ekrell@ucla-cs.UUCP (01/30/85)
> >< > > I read this somewhere: a procedure-oriented language represents the > > behavior of a program by describing the effect of applying procedures > > to different kinds of arguments (here procedures being a broad term > > including assignments, arithmetic operators, etc). > > An object-oriented language does it by describing the effect of applying > > different procedures (methods) to a specific object. > > > > The definition is lacking two important things: the definition of 'arguments' > and the definition of 'objects'. After all, an argument could, in some > contexts be considered an object. I've read several definitions of what people think is object-orientation and I think that most of them confuse it with ADTs (Abstract Data Types), which are "objects" in the sense that they represent physical or abstract objects such as a person or a stack, where the specification of the operations on these objects is separated from their implementation. This is nice (Information Hiding principle, etc) but that doesn't make a language object-oriented. Ada and Modula-2 have all these goodies but that doesn't make them object-oriented languages. I think people who know SMALLTALK would agree with me. It is true that there's an analogy in applying a method to an object and an operation to an ADT, but the way an expression "f(x)" would be evaluated in a object-oriented language is "look at the type of object x is; find a method called f defined for that object and apply it to x". In a procedure-oriented language it would be "look at the definition of f and apply f to x". It's clear, then, that an object-oriented language has overloading since you could have methods with the same name for different objects. However, the presence of overloading in a language (like ADA) doesn't mean it is object-oriented... -- Eduardo Krell UCLA Computer Science Department ekrell@ucla-locus.arpa ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!ekrell
mwm@ucbtopaz.CC.Berkeley.ARPA (01/30/85)
Since we're into definitions, let me present my favorite version. This is from (I think - everything is stacked away in boxes) Tim Rench's SNot paper already mentioned here. Examples are not meant to reflect any real language. 'Data Encapsulation' - Provides modules, and data objects that only functions in the appropriate module can touch. For instance: MODULE IntStack is Push, Pop ; STRUCT Stack is ... ; PROCEDURE Push is ... ; PROCEDURE Pop is ... ; END IntStack ; x is IntStack ; y is Int ; x.Push(10) ; y := x.Pop() ; 'Data Abstraction' - An improved form of encapsulation, wherein the abstraction can be reused on different data types. For instance: MODULE Stack(T is TYPE) is Push, Pop ; ... ; END Stack ; MODULE List(T is TYPE) is ... ; END List ; x is Stack(Int) ; y is Stack(List) ; z is Int ; w is List ; x.Push(10) ; y.Push([a, b, c]) ; w := y.Pop() ; z := x.Pop() ; Finally, a programming language is 'Object Oriented' if *everything* must be encapsulated. In other words, Concurrent Euclid is 'Object Oriented,' and provides encapsulation, but not abstraction. Smalltalk is 'Object Oriented,' and provides abstraction. CLU is not 'Object Oriented,' but does provide abstraction. I prefer this definition because it gives a high degree of resolution when you want to talk about a language (admittedly, it takes a lot of buzz words). This would be far better than allowing 'Data Encapsulation' to disappear and 'Data Abstraction' and 'Object Oriented' to become synonyms. I think it even correctly captures the methodology split the smalltalk people like to talk about. If everything is in a module, then all data has a set of routines (messages) that can be used on it, and all routines have a set of data they are associated with. This should make thinking about things as data objects that reply to messages easier. Of course, whether the methodology gets used depends on the programmer. <mike
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
crm@duke.UUCP (Charlie Martin) (02/17/85)
Fundamentally, Smalltalk doesn't do anything differently from Ada; it
just hides it differently.
Trying to give a talk on Object-Oriented Programming, I searched high
and low (through all the Smalltalk books, for example) for a definition
of OOP -- and found none. Either we have to take it as an undefined
term, or we ought to find a definition. I'm unsatisfied with the
definition that has been offered by several people ("It's what Smalltalk
does that no-one else does") because a) I can't find that (tell me the
fundamental difference between passing messages and passing parameters
by name) and b) it makes "Object-Oriented Programming" == "SmallTalk
Programming" which seems to eliminate any chance of using the term or
the idea usefully in anything BUT SmallTalk.
Personally, I think the term should be discarded as being too fuzzy for
scientific use. First, let's find out just what an Object is!
--
Opinions stated here are my own and are unrelated.
Charlie Martin
(...mcnc!duke!crm)
"I am not a number, I'm a free variable!"ted@scc.UUCP (Ted Goldstein) (02/19/85)
> Fundamentally, Smalltalk doesn't do anything differently from Ada; it > just hides it differently. > > Trying to give a talk on Object-Oriented Programming, I searched high > and low (through all the Smalltalk books, for example) for a definition > of OOP -- and found none. Either we have to take it as an undefined > term, or we ought to find a definition. I'm unsatisfied with the > definition that has been offered by several people ("It's what Smalltalk > does that no-one else does") because a) I can't find that (tell me the > fundamental difference between passing messages and passing parameters > by name) and b) it makes "Object-Oriented Programming" == "SmallTalk > Programming" which seems to eliminate any chance of using the term or > the idea usefully in anything BUT SmallTalk. > > Personally, I think the term should be discarded as being too fuzzy for > scientific use. First, let's find out just what an Object is! > > -- > Opinions stated here are my own and are unrelated. > > Charlie Martin > (...mcnc!duke!crm) > > "I am not a number, I'm a free variable!" A friend of mine defines an `object' as "Data with an Opinion." That is, using the type of the object, a function/operation is selected which is appropriate to that type. This is nothing new to computer languages. Addition is different for integer and floating point numbers. Yet syntactically a programmer coding in many high level langauges write a + b and leave the work to the compiler to determine whether to use integer add or floating add primitives. Smalltalk-80, and other object-oriented languages promote this concept so that it is uniformally applied to all operations and types, whether they are system defined or user defined. But to come up with a less fuzzy opinion: More formally, an "Object" is a type defintion with a closure on what operations may be performed on it. Objects are similar to ADA's packages when used in conjunction with ADA generic calls. Almost all Smalltalk-80 objects are defined in a hierarchical fashion. ADA Packages can be hierarchically composed too, but the generic operations cannot be used after the first level of the hierarchy. The hierarchical nature is natural in Smalltalk-80 because binding between the generic call and the actual function (method) is dynamic. That is, it occurs at run time. I think Smalltalk-80 is superior to ADA in this respect, because more code is re-usable because operations (when apropriate) tend to be defined at higher levels of the hierarchy. ADA generic operations are selected by the type of all of its arguments, while Smalltalk operations are selected by the first argument only. C++ is similar to ADA in this way; multiple argument type binding on generic operations are a property of compile time bindings. C++ combines some of Smalltalk-80 and ADA's power. Like ADA, C++ has generic operations. These are frequently resolved at compile time, and thus incur no addtional penalty. Some generic operations in a hierarchically defined types cannot be known at compile time. Smalltalk and C++ both have dynamic binding available when the inheritance cannot be determined (This is known as virtual functions in C++). ADA must know all package defintions and make resolve all generic functions at compile time. I hope we see more of C++ in the world. -- Sincerely, Ted Goldstein, Freelance Consultant "Don't thank me, thank Uni" from 'This Perfect Day' by Ira Levin ihnp4!pesnta -\ fortune!idsvax -> scc!ted ucbvax!twg -/ Santa Cruz, California (408) 662-3112