Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: What is OOP? Date: Mon, 17 Mar 2025 10:17:51 -0700 Organization: A noiseless patient Spider Lines: 121 Message-ID: <86h63rr2yo.fsf@linuxsc.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 17 Mar 2025 18:17:55 +0100 (CET) Injection-Info: dont-email.me; posting-host="9451e75d3100499019131ace8752e027"; logging-data="630062"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+4VUrOIx4459SF7/sKng5uqQwkUvTXaaI=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:IOHF2W6E1ArqtQbfqSiA7HvHZxQ= sha1:PQbsLJXhzTBRezG+Qj8XrwG6pJo= Bytes: 6743 ram@zedat.fu-berlin.de (Stefan Ram) writes: > Rosario19 wrote or quoted: > >> what is oo programming? > > Alan Kay coined the term, and, in 2003, I asked him: > > What does "object-oriented [programming]" mean to you? > > . He answered in an e-mail: > > |OOP to me means only messaging, local retention and protection and > |hiding of state-process, and extreme late-binding of all things. > > . My personal interpretation (taking the above source and my > own observations into account): I appreciate your efforts in pursuing this and in describing what you think it all means. I'm glad to see a discussion about OOP that goes beyond the common misunderstandings of what is meant. I would like to respond to your comments with my own understanding of how Alan views these areas. I should explain that I have talked with (and also listened to) Alan enough so that I think I have a pretty good understanding of what his views are here, but the comments below are just my impression of his thoughts. > An object is an imaginary building block that contains states > and procedures and can only be accessed from the outside by > sending messages. The object decides how it reacts (within the > scope of its specification) to a specific message. (runtime > model) An object is a blob about which nothing is known except that it is able to receive messages and act on them (which may include doing nothing at all). > In object-oriented programming, programs describe under which > conditions which messages are sent to object expressions at > runtime: For this purpose, there is a dispatch specification > that defines the recipient object expression and the message > to be sent. This dispatch definition can also be regarded as > an expression whose value is then determined by the recipient > object (as a type of response). (source code model) The key property of object-oriented programming is that sending a message is the only way to accomplish anything. Sending a message may start an activity and never return, or it may finish and return an object value, with the understanding that "object value" always means using pointer semantics. There are no data values as such; the only kinds of values in OOP are objects. In addition to sending messages, Smalltalk has ways of using identifiers to refer to an object, of combining or sequencing message send constructs, and of assigning an object value (which again uses pointer semantics) to a named object holder (some form of identifier), but these capabilities are secondary to the key property described in the previous paragraph. > It must be possible to determine which object receives a > particular message (late binding) as late as possible (i.e. at > runtime during the evaluation of the dispatch determination): The late binding that Alan is talking about is the binding of messages to processing activity. Note the contrast with calling a function, where the binding of name to what processing is done is static rather than deferred. > For this purpose, the recipient object can be specified again > in the dispatch determination itself by means of an expression > that is only evaluated at runtime as late as possible (runtime > polymorphism). It's true that the returned object value of a sent message can be used to send a further message, but that is not an occurrence of binding. Calling a function through a pointer-to-function relies on information known only at runtime, but no binding is taking place for that (except perhaps for the mapping of a variable name to a location holding the pointer-to-function value). > Yes, I really think it is better to say that we send messages > to expressions because which object the expression represents > is only determined shortly beforehand and can be different > each time the same code is run several times. Messages are always sent to objects, not to expressions. Obviously determining an object value at runtime is useful, but it isn't any different than determining any other value at runtime. Calling a function in C that takes two arguments and returns their sum depends on values determined at runtime, but that nothing to do with late binding. The key point is that, having gotten back an object, we can't do anything with it except send it a message, and the binding of message to what processing activity will occur always takes place at the last possible moment. > But there's something else of equal importance! It's the > insight by Uncle Bob (Robert C. Martin) about when procedural > code is better and when object-oriented code is better. > > |Procedural code (code using data structures) makes it easy to > |add new functions without changing the existing data > |structures. OO code, on the other hand, makes it easy to add > |new classes without changing existing functions. > Robert C. Martin > > |Procedural code makes it hard to add new data structures > |because all the functions must change. OO code makes it hard > |to add new functions because all the classes must change. > Robert C. Martin Both of these comments make the mistake of conflating OOP with programming in languages that have classes. That isn't what Alan meant by object-oriented programming. That Smalltalk has classes is incidental to what is meant by object-oriented programming; classes in Smalltalk are simply a way of implementing the abstract idea of "object-oriented programming" that had started in Alan's thinking, and actually much earlier than Smalltalk or even Simula.