[TUHS] A la carte menu of OO features or properties

[TUHS] A la carte menu of OO features or properties

[Don Hopkins]

[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]

The properties of object oriented programming are better described as an la carte menu like a cafeteria buffet or smörgåsbord, than a point, line, or continuum. 

http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html>

Paul Graham: Reese Re: OO

(Jonathan Rees had a really interesting response to Why Arc isn't Especially Object-Oriented, which he has allowed me to reproduce here.)

Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list.

	• Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference.

	• Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out.

	• Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types.

	• Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types.

	• Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends).

	• All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this.

	• Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.)

	• Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.)

	• Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names.

[…]

(See the web page and the original thread for a discussion of which languages implement which of the above features.)

http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html>

https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail/e-lang/2001-October/005852.html <https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail/e-lang/2001-October/005852.html>

-Don


[-- Attachment #2: Type: text/html, Size: 4515 bytes --]