[kazinator]

"Object-oriented programming" in its basic form means that the data manipulated in a computer program is self-describing. We can ask a datum, "what are you? what type?". The functions of that program are organized around data. This is in contrast with the form of programming in which data is just some storage, which is given a meaning by the algorithm that operates on it; it is not self-describing.

Self-describing data lets us then have generic operations. For instance, if an object hold a sequence of other object, we can create an operation which extracts the N-th one. And we can make that same operation work for an object which is a character string, vector, list. This is because the function can inquire the object what it is, and then call the appropriate concrete implementation which does the right thing for that type.

This leads us to realize that type is connected to the operations which are applicable. Those objects are somehow of the same "kind". This gives rise to the concept of subtyping and substitutability: a string is a kind of sequence and so is a list and we can have operations on sequences.

The non-object-oriented concepts are all that cruft from various languages which tries to strangle OO: virtual base classes, protected members, methods within class scope, scope resolution, copy constructors, yadda yadda ad nauseum ... We are led to believe that OO requires this or requires that. It's not OO if there is no encapsulation. It's not OO if there is no language-enforced "information hiding". It's not OO if there is no private/public access mechanism. It's not OO if method calls aren't represented as message passing. It's not OO if methods aren't in a compile-time class scope together with data members. ...

[tailrecursion]

Kazinator's comment struck me as a lucid definition. APIs and ADTs let the thing's behavior define the thing, and subtyping and substitutability emerge from thinking about generic operators defined on more than one kind of datum.

My bet is even Smalltalk programmers don't think of eggs as knowing how to scramble themselves; but eggs do have an API, a behavior, that makes them distinct from other kinds of objects and at the same time shares characteristics with other objects, such as weight and dimensions.

I can assemble a list of eggs, elephants, and cars, and write "take the sum of the weights of all the objects". Although these objects are of different kind, they share a common characteristic that would be exploited naturally by any language user. Exploiting multiple "views of a thing" is a feature of English ("natural language") and to my mind is a feature of any successful "generic programming" computer language.

Processes communicating by asynchronous message passing is a better simulation of the familiar world; but that vision is not realized by Smalltalk, wherein messages are passed synchronously. What we want from language is the ability to write powerful sentences and have them mean something to the machine -- as long as the computer and human agree on the meaning. The better part of this power comes from a sophisticated treatment of type and generic operators.

[l_dopa]

You just described parametric polymorphism, which has nothing to do with objects or runtime type information.

[kazinator]

"has nothing to do" ... says you! I didn't describe static parametric polymorphism. Some of the things I described are doable with static parametric polymorphism in some limited circumstances.

[l_dopa]

Well, you described parametric polymorphism (a generic Nth function) and then switched to talking about dispatching on tags at runtime. You are mistaken; those really are completely unrelated concepts.

[asuffield]

Please, identify which things can't be done with parametric polymorphism. It is not clear what you are referring to.