Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site tove.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!tektronix!decvax!bellcore!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!tove!koved From: koved@tove.UUCP (Larry Koved) Newsgroups: net.lang,net.lang.st80 Subject: Re: Re: What is Object-Oriented Message-ID: <119@tove.UUCP> Date: Tue, 5-Feb-85 23:21:53 EST Article-I.D.: tove.119 Posted: Tue Feb 5 23:21:53 1985 Date-Received: Tue, 12-Feb-85 06:26:55 EST References: <3013@umcp-cs.UUCP> <117@tove.UUCP> Organization: U of Maryland, Laboratory for Parallel Computation, C.P., MD Lines: 94 Xref: watmath net.lang:1418 net.lang.st80:188 > 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