alan@rnms1.paradyne.com (Alan Lovejoy) (04/23/89)
In article <823@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes: >Some previous articles discussed the "object-orientedness" (what a >word!) of C++, Objective C and various other languages. Let me add >me 2 cents worth, even though I usually regret posting my opinions >to USENET afterwards ... :-) Hey, if nobody ever posted controversial articles, usetNET would be useLESS! So don't be shy. >Today, most people can probably live with the following "definiton": >(We'll soon hear from those who can't :-) > >A language is OO if >1) it supports data encapsulation (information hiding, abstract data types), It must have classes. A class can be instantiated. Data encapsulation is just a synonym for information hiding. Sine you mention abstract data types in your definition, however, you get at least 1/2 credit. A class might be operationally defined as an abstract data type with information hiding, since a data type is instantiable. But many will argue that it still isn't a class unless it also has inheritance and a set of functions bound to instances of the class (messages). If abstract data type implies all this, or at least implies a set of bound functions, then the distinction between a class and an abstract data type begins to be rather "academic" (differing at most by +/- inheritance). So what's the difference between a class and an abstract data type? Comments? >2) it supports inheritance (subclassing, extensible record types, ... ) > and Extensibilty is NOT the same thing as inheritance. Inheritance permits the definition of a new class in terms of the differences between the new class and the superclass. An extension is only one type of difference. There are also changes in the structure or function of inherited characteristics and simple removal of inherited characteristics. Inheritance can be thought of as "polyparameterization"--to coin a new term. If a class were a parameterized abstraction (a "generic package" in Adaspeak) where every characteristic were parameterized, then instantiating instances of the class abstraction with different parameter sets would achieve the same effects as can be obtained using inheritance. That is why Smalltalkers sometimes refer to classes that were designed to be inherited as "abstract classes." Each subclass does what amounts to parameter substitution by overriding the inherited methods. >3) it supports determination of the procedure body to be executed at the > time of the actual procedure call (message passing, virtual functions). Your language is ambiguous. "At the time of the actual procedure call" could mean either at run time or at compile time. If only at compile time, then this is the same thing as overloading. If also at run time, then it is dynamic message-to-method binding. Your parenthetical comment indicates you are referring to dynamic method binding (for which overloading is a prerequisite). I agree. In an earlier posting I listed overloading as a requirement, but not dynamic method binding. That was an oversight, which your posting made me aware of. I *knew* better, too. Arghhhh!! I was thinking about polymorphism at the time. With full polymorphism, one must have dynamic method binding (the value of a reference--such as a function address--must be a computable value). My list also included polymorphism, but the purpose of the list was to define the ideal OO language. Your list (as I have ammended it) is probably close to what the consensus would be for the minimum requirements. Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. _________________________Design Flaws Travel In Herds_________________________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
marti@ethz.UUCP (Robert Marti) (04/26/89)
In article <5971@pdn.paradyne.com>, alan@rnms1.paradyne.com (Alan Lovejoy) writes: | In article <823@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes: | >A language is OO if | >1) it supports data encapsulation (information hiding, abstract data types), | | It must have classes. A class can be instantiated. Data encapsulation is | just a synonym for information hiding. Sine you mention abstract data types | in your definition, however, you get at least 1/2 credit. Thanks for the 1/2 credit :-) At any rate, class instantiation is not all that important to me, since it can be "simulated" in a straightforward manner within more conventional languages. I do agree that it's a nice feature to have, though. | So what's the difference between a class and an abstract data type? | Comments? Same difference as far as I am concerned. | >[ A language is OO if ] | >2) it supports inheritance (subclassing, extensible record types, ... ) | > and | | Extensibilty is NOT the same thing as inheritance. Inheritance permits | the definition of a new class in terms of the differences between the new | class and the superclass. An extension is only one type of difference. Agreed. Ideally you'd want to extend, restrict and override definitions inherited from a superclass. | >[ A language is OO if ] | >3) it supports determination of the procedure body to be executed at the | > time of the actual procedure call (message passing, virtual functions). | | Your language is ambiguous. "At the time of the actual procedure call" could | mean either at run time or at compile time. I meant at run time, of course. | If only at compile time, then | this is the same thing as overloading. If also at run time, then it is | dynamic message-to-method binding. Your parenthetical comment indicates | you are referring to dynamic method binding (for which overloading is a | prerequisite). More violent agreement here :-) | Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informationssysteme ETH-Zentrum CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti