kempf@hplabsc.UUCP (Jim Kempf) (01/07/86)
The phrase "object oriented" has been used to describe C++. While the semantics of defining "object oriented" can get tricky, I wonder if this term should be used to describe C++. A crucial difference which I see between C++ and more unambiguously object oriented languages, like Objective C, Smalltalk, and Lisp Flavors, is that the unit of encapsulation in C++ is the *class* rather than the individual member of that class. Member functions can access the "instance variables" (or private parts, as they are called in C++) of any member of the class. This has important implications for encapsulation and data security. In general, I find this aspect of C++ places it into the category of "abstract type"/"module" languages, like Modula-2 and CLU rather than "object-oriented" languages, like Smalltalk and Lisp Flavors. While there are pros and cons to both approaches, there is probably something to be said for making the distinction clear. For example, no one would call Lisp an "Algol-like" language, nor C a "symbolic processing language", even though it's possible to do Algol-like things in Lisp (Common Lisp even has a notion of block structuring) and symbolic processing in C. Jim Kempf kempf@hplabs
jes@ulysses.UUCP (Jonathan Shopiro) (01/11/86)
> The phrase "object oriented" has been used to describe C++. > While the semantics of defining "object oriented" can get > tricky, I wonder if this term should be used to describe C++. A > crucial difference which I see between C++ and more unambiguously > object oriented languages, like Objective C, Smalltalk, and > Lisp Flavors, is that the unit of encapsulation in C++ is the > *class* rather than the individual member of that class. > Member functions can access the "instance variables" (or > private parts, as they are called in C++) of any member of > the class. This has important implications for encapsulation > and data security. > > In general, I find this aspect of C++ places it into the category > of "abstract type"/"module" languages, like Modula-2 and CLU > rather than "object-oriented" languages, like Smalltalk and > Lisp Flavors. > > Jim Kempf kempf@hplabs You are right that C++ member functions can access private members of all objects of their class, but I think it is still reasonable to call C++ O-O, because when a member function executes, it always is as a member of some particular object, and that object is part of the function's environment. For example, if 'MyType' is a class with data member 'x' and function member 'foo' (suppose 'foo' has no arguments). class MyType { int x; void foo(); }; Now suppose 'a' and 'b' are external or accessible static objects of class MyType. MyType a, b; In the body of 'foo' I can access the members of both 'a' and 'b' but I have to name the object explicitly. void MyType::foo() { // ... MyType zot; // ... a.x + b.x + zot.x // } However this kind of code is rarely seen and I agree, more modular than object oriented. (Reflecting its heritage, C++ is more concerned with allowing you to do the things you want than preventing you from doing things you shouldn't). The usual case is that the object is implicit -- that is, part of the function's environment. void MyType::foo() { // ... x // } Here 'x' refers to THE object (called 'this' in C++ or 'self' in Smalltalk-80(TM)), so if I execute a.foo() then 'x' refers to 'a.x' and similarly for 'b' or any other object of class MyType. My own favorite litmus test for O-O languages is that it should be straightforward to have a bunch of different classes that each have a member function 'foo' (different in each class), and have a heterogeneous list that can hold a mixture of objects from any of those classes, and pass the list to a function that can properly execute 'foo' for each element of the list. Of course C++ passes this test. The distinction between C++ and Smalltalk-80(TM) in this regard is interesting -- in ST80 you can put any objects on a list, but if you get the wrong kind of object (whose class doesn't have a 'foo') on the list, you get a run-time error when you try to execute 'foo' for that object. In C++ the classes all have to be derived from a base class that has a member function 'foo' (this doesn't seem to be too much of a problem in practice), but the error of putting the wrong kind of object on the list is caught at compile time. Also the (admittedly tedious) compilation of C++ yields much better performance at run-time. -- -- Jonathan Shopiro AT&T Bell Laboratories 600 Mountain Avenue Murray Hill, NJ 07974 (201) 582-4179 allegra!ulysses!jes
gwyn@BRL.ARPA (VLD/VMB) (01/12/86)
Jim Kempf has a good point. "Object-oriented" probably should be reserved for languages that really are. Since "object-oriented" and "good" are not synonymous, this shouldn't bother anybody.
bs@alice.UucP (Bjarne Stroustrup) (01/13/86)
> From allegra!ulysses!mhuxr!mhuxt!houxm!ihnp4!pesnta!hplabsc!kempf > From: kempf@hplabsc.UUCP (Jim Kempf) > Subject: Is C++ Object Oriented? > Organization: Hewlett Packard Labs, Palo Alto CA > > The phrase "object oriented" has been used to describe C++. > While the semantics of defining "object oriented" can get > tricky, I wonder if this term should be used to describe C++. A > crucial difference which I see between C++ and more unambiguously > object oriented languages, like Objective C, Smalltalk, and > Lisp Flavors, is that the unit of encapsulation in C++ is the > *class* rather than the individual member of that class. > Member functions can access the "instance variables" (or > private parts, as they are called in C++) of any member of > the class. This has important implications for encapsulation > and data security. > > In general, I find this aspect of C++ places it into the category > of "abstract type"/"module" languages, like Modula-2 and CLU > rather than "object-oriented" languages, like Smalltalk and > Lisp Flavors. While there are pros and cons to both approaches, > there is probably something to be said for making the distinction > clear. The distinction was made clear in ``Data Abstraction in C'' BLTJ Oct. 1984 and is implied in the ``Rules of Tumb'' in the C++ book, but I don't believe it is of first order importance. C++ supports object oriented programming because it has an inheritance mechanism. This, I believe, is the crucial tests, not the issue of the unit of protection. Furthermore, if you consider it important to ensure that interaction between objects of a C++ class is restricted to calls of member functions, then that is trivially done (by human or machine). This implies that any tricks a compiler/interpreter can do by taking advantage of object-encapsulation can be done in in a language with class-encapsulation for the cases where the strict object-encapsulation is desired/specified. C++'s inheritance mechanism is very similar to Simula67's so C++ is in good company. I usually say that ``C++ supports object oriented programming'' or ``C++ provides facilities for object oriented programming'', not ``C++ is an object oriented language''. In other words, ``object oriented'' is a style of programming, not a langauge feature. Not every application is best handled using an object oriented style, so C++ also supports other styles. For example, many arithmetic types are best handled using the data abstraction paradigm. C++ is probably best understood as a ``Multi-paradigm language'' in the tradition of C where the emphasis is on facilities of doing (presumably interesting) things rather than on facilities on preventing you from doing (presumably bad) things. - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill, NJ) PS ``private parts'' is not the C++ term for an instance variable, the term is ``object''.