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!wildbill
macrakis@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!koved
robert@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
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
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
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