koved@umcp-cs.UUCP (Larry Koved) (02/05/85)
After reading the many definitions of what "object-oriented"
means, I have decided to put in my 2 cents (for whatever that
is worth!).
Object-oriented is a rather vague term which has been applied
to many different concepts. Two areas in which OO has been
used is in programming languages and computer systems (hardware
and operating systems). Its roots date back to about 1966 in
an infamous article written by Dennis and Van Horn (CACM, March 1966).
Many ideas and concepts were expanded from that paper and developed
during the late 60's and 70's. Many systems which evolved during
this era were interested in abstraction mechanisms (data types, etc.),
and protection of data (and data objects) in computing systems.
What eventually evolved were systems such as Hydra, CLU, Smalltalk,
Multics, Intel 432, IBM System/38, Sward, and many others which
I can't remember offhand.
A central themes of these systems was data, procedures, protection,
and abstraction. Data is "encapsulated" into an object (of a type)
which has a set of protected procedures which are allowed to manipulate
the representation of the object. Only those procedures which are
defined for the data type are allowed to manipulate the representation
of the object. Note that procedures are also considered to be
objects (procedure objects). Also, objects can contain other objects.
(this also gets into the issue of data abstraction.)
I could go on for pages, but I will leave that for another time.
I will not pontificate on this subject much more...except:
There are two related issues in programming language design which
frequently gets confused with OO programming: overloaded operators
and inheritence. Having overloaded operators and/or inheritence
(single or multiple) does not determine whether or not a language
is OO. Each of these is an issue in programming language design
which can and should be considered seperately from the OO issues.
There are languages which use overloading and/or inheritence, but
are not OO, and visa versa.
Finally, it should also be noted that there are different degrees of
being OO. Smalltalk is almost at one extreme, while Modula-2 is almost
at the other extreme. The performance of the language (instructions
per second) is a major consideration in deciding the degree to which
a language's design is OO. Being extremely OO is expensive in
processing time and/or space.
I will now get down off my soapbox and await for your reactions (flames).
--
Spoken: Larry Koved
Arpa: koved.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!kovedmark@tove.UUCP (Mark Weiser) (02/06/85)
In article <3013@umcp-cs.UUCP> koved@umcp-cs.UUCP (Larry Koved) writes: >There are languages which use overloading and/or inheritence, but >are not OO, and visa versa. I'd be interested in an example of inheritence without OO. What one inherits in OO is operators and local variables. Is there something else to inherit? >Finally, it should also be noted that there are different degrees of >being OO. Smalltalk is almost at one extreme, while Modula-2 is almost >at the other extreme. Not Fortran or Forth at the other extreme? Modula-2? Do you mean there are different KINDS of OO, with Modula-2 and Smalltalk being prototypical examples, or do you really mean degrees? >The performance of the language (instructions >per second) is a major consideration in deciding the degree to which >a language's design is OO. Being extremely OO is expensive in >processing time and/or space. Now this is an interesting issue. Why should OO be expensive? It need not be, because it need not be a runtime feature of a language. Smalltalk is mostly interpreted, and so is slow for that reason, not because it is OO. The Maryland Flavors Package under Franz Lisp allows compiled methods, flavors etc, and so runs not too much slower than bare Lisp. And a completely statically checked and implemented OO language should be as fast as any other at runtime. (Is c++ something like this? I'm not sure.) Might be slow to compile with current technology--but we haven't had much practice at building fast OO compilers. -- Spoken: Mark Weiser ARPA: mark@maryland Phone: +1-301-454-7817 CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
koved@tove.UUCP (Larry Koved) (02/06/85)
> In article <3013@umcp-cs.UUCP> koved@umcp-cs.UUCP (Larry Koved) writes: > >There are languages which use overloading and/or inheritence, but > >are not OO, and visa versa. > > I'd be interested in an example of inheritence without OO. What one > inherits in OO is operators and local variables. Is there something > else to inherit? > Lisp Flavors (which you mention below) is an example of a lanugage which has is a combination of object-oriented and non-object-oriented features in a single language. Lisp is not object oriented, but the flavors package in lisp is object oriented. I would not classify Lisp as an object oriented language; only the flavors part is object oriented (to a degree). I do not know of a language which only has inheritence, but not objects. A language could be defined in which a data type could inherit properties of an existing data type. For example: In Pascal, if a type (call it A) uses another type in its definition (call it B), then type A inherits properties of type B. My thoughts in this area are a little fuzzy since I have not thought about it very much. > >Finally, it should also be noted that there are different degrees of > >being OO. Smalltalk is almost at one extreme, while Modula-2 is almost > >at the other extreme. > > Not Fortran or Forth at the other extreme? Modula-2? Do you mean > there are different KINDS of OO, with Modula-2 and Smalltalk being > prototypical examples, or do you really mean degrees? I would probably like to stick with my original statement of there being extremes in being OO. Yes, Modula-2 and Smalltalk prototypical examples of OO languages. The degrees of which I am speaking are the degrees to which the language makes the sharp distinction about object manipulation. In particular, how well the language protects the objects, their internal representations and access to the procedures which manipulate the representation. For example, in Modula-2 (and ADA for that matter), you can hide the representation and implementation of an object in the implementation of the modules. The definition of the object and the procedures which manipulate the objects can be made public (if so desired), but those procedures which are not defined to manipulate the object can not gain access to the object's representation. The same is true of Smalltalk. The difference is that Smalltalk attempts to enforce the rules across all objects which are defined and instantiated. This is not so for Modula-2 and ADA where you can define objects where any procedure can manipulate the internal representation. The difference is that Modula-2 allows object representation protection, but Smalltalk always requires that the object be protected. > > >The performance of the language (instructions > >per second) is a major consideration in deciding the degree to which > >a language's design is OO. Being extremely OO is expensive in > >processing time and/or space. > > Now this is an interesting issue. Why should OO be expensive? > It need not be, because it need not be a runtime feature of a language. > Smalltalk is mostly interpreted, and so is slow for that reason, > not because it is OO. The Maryland Flavors Package under Franz > Lisp allows compiled methods, flavors etc, and so runs not too > much slower than bare Lisp. And a completely statically checked > and implemented OO language should be as fast as any other at runtime. > (Is c++ something like this? I'm not sure.) > Might be slow to compile with current technology--but we haven't had > much practice at building fast OO compilers. Yes, the issue about performance of systems which require protecton is interesting. If and when type checking can be done statically, the cost is much lower. You make refrence to flavors. The flavors part of lisp is object oriented, but the rest of lisp upon which flavors is implemented is not. I suspect that this makes a difference. When looking a security (protection) oriented systems, there are costs incurred due to the protection mechanisms. Once you start to do multi-programming, then you get many different types of protection problems which do not occur in uni-programming systems (and languages). This is also a factor in why protected systems incur a heavy cost at run-time. > -- > Spoken: Mark Weiser ARPA: mark@maryland Phone: +1-301-454-7817 > CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark > USPS: Computer Science Dept., University of Maryland, College Park, MD 20742 -- Spoken: Larry Koved Arpa: koved.umcp-cs@CSNet-relay Uucp:...{allegra,seismo}!umcp-cs!koved
rmc@panda.UUCP (R. Mark Chilenskas) (02/11/85)
One article in the "quest for a definition of object oriented" requested an example of a type of inheritance which is not included in Smaltalk. I think that the AI "knowledge representation languages" such as Pearl or Omega. They provide inheritance of demons which are fired when the "status" of objects change (the whenever a new object of the class is created, when one is changed, when one is disposed of...) While this can probably be handled fairly simply by hacking class specific New messages etc., it is not provided in the base ST80 language. I think that some articles are confusing the language ST80 with the programming environment provided by Xerox to go with the language. One could consider an improved Modula-2 programming environment where one could modify, recompile, and re-link the implementation module for an object just as dynamically as one can in ST80. It would require keeping a procedure dictionary lying around so one could direct requests to the most recent copy of the method / implementation module, or linking implementation modules indirectly using a scheme similiar to the VMS runtime system vectors. I don't know if Lilith does this sort of thing or not, but other Modula systems i have seen consider Modula just another Pascal-like language. ST80 feels more like a Lisp system becuase it has better program development support. This is an implementation decision and is not dictated by the language. I basically don't currently believe that a definition of what "object oriented language" means is currently possible. We as computer scientists are still at the stage of pointing and saying ST80 is for sure and BASIC is certainly not object oriented. This is actually ok. Maybe Mathematics makes definitions before there is a consensus in the community about what words mean, but even that is debatable. What we are doing now is pointing and coming up with examples. Eventually a consensus will arise, but by that time all the formal definition will be good for is introducing students to a concept which is well understood by the computer science community as a whole. Enjoy, R Mark Chilenskas decvax!genrad!panda!rmc
cca@pur-phy.UUCP (Allen) (02/11/85)
I just can't resist any longer. Here's a quote from Dan Ingalls "Design Principles Behind Smalltalk" article in the August '81 Byte: "... Smalltalk provides a much cleaner solution: it sends the name of the desired operation, along with any arguments, as a message ... with the understanding that the receiver knows best how to carry out the desired operation. Instead of a bit-grinding processor raping and plundering data structures, we have a universe of well-behaved objects that courteously ask each other to carry out their various desires." Alas, it's back to raping and plundering for me, lacking a Smalltalk machine.... Charlie Allen ..pur-ee!pur-phy!cca
rcd@opus.UUCP (Dick Dunn) (02/14/85)
> I just can't resist any longer. Here's a quote from Dan Ingalls > "Design Principles Behind Smalltalk" article in the August '81 Byte: > > "... Smalltalk provides a much cleaner solution: it > sends the name of the desired operation, along with any > arguments, as a message ... with the understanding that > the receiver knows best how to carry out the desired > operation. >... The fundamental asymmetry between the object which does the sending and the arguments (which are also objects) is a giant flaw in this model. > ...Instead of a bit-grinding processor raping > and plundering data structures, we have a universe of > well-behaved objects that courteously ask each other to > carry out their various desires." Except that some of those objects bodily grab others (the arguments) and cart them off to parts unknown, slaves in bondage to their nefarious purposes. If you can convince yourself that, in an expression such as "x+y", the roles of x and y are FUNDAMENTALLY different--i.e., that x is active but y is passive--then perhaps you can believe in Smalltalk. I can't. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator!
vermeule@gumby.UUCP (02/26/85)
hdhdjhdJ J q ZZ> I just can't resist any longer. Here's a quote from Dan Ingalls > > "Design Principles Behind Smalltalk" article in the August '81 Byte: > > > > "... Smalltalk provides a much cleaner solution: it > > sends the name of the desired operation, along with any > > arguments, as a message ... with the understanding that > > the receiver knows best how to carry out the desired > > operation. > >... > > The fundamental asymmetry between the object which does the sending and the > arguments (which are also objects) is a giant flaw in this model. > > > ...Instead of a bit-grinding processor raping > > and plundering data structures, we have a universe of > > well-behaved objects that courteously ask each other to > > carry out their various desires." > > Except that some of those objects bodily grab others (the arguments) and > cart them off to parts unknown, slaves in bondage to their nefarious > purposes. > > If you can convince yourself that, in an expression such as "x+y", the > roles of x and y are FUNDAMENTALLY different--i.e., that x is active but y > is passive--then perhaps you can believe in Smalltalk. I can't. > -- > Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 > ...Cerebus for dictator! *** REPLACE THIS LINE WITH YOUR MESSAGE ***
jans@mako.UUCP (Jan Steinman) (03/02/85)
Dick Dunn writes: > ... some of those objects bodily grab others (the arguments) and cart them > off to parts unknown, slaves in bondage to their nefarious purposes. Hold on there, Dick. I don't think you really understand what's going on in Smalltalk. An object is in control of it's own private memory (known as "instance variables") and doesn't get abused by other objects unless it agrees to (implements a selector for) such abuse. Also, (excepting UCB's latest implementation) only object *references* are passed around as arguments. An object can ask another object "what is your value", "change your value to X", or even "destroy thyself", but the object doesn't do damned thing (except report that it's confused by the request) unless an appropriate response exists in it's protocol, or the protocol of it's superclass chain. -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::