What should be a focused idea will often lead me to some major (essential) digressions in fundamentals. For example, while writing notes for a small essay1, I had to think hard about a couple of things, one of which was the idea of objects. I have spent some effort over the years trying to understand what OO really means, and thought I had a good handle on it2.
The capability-security-model uses objects3 (and is now properly known as the object-capability-model, aka ocaps), and the issue I was exploring lead me into some difficulties. I have a prejudice for generic functions, and thus the separation of type and behavior4. Simula-like (e.g. Java) languages package the two together. I found it easy to think about ocap issues with Simula-like objects, but confusing with generic methods.
I wanted to use the correct terminology in my notes, and ultimately in any resulting writings. That would help me keep the ideas straight, and my readers wouldn't have to decode my private language. However, I believed that the current usage was terribly confused.
Specifically, the popular understanding of "class" is wrong, and makes it difficult to talk about generic functions. I managed to restrain my impulse of correcting the wayward and imposing my meanings. I tried to look it up.
Apparently, Armstrong, "The Quarks of Object-Oriented Development"5, thinks OO means Simula-like objects, and wants "class" to mean type+methods. I believe this is a typical hierarchical approach to definitions, and I've found it more fruitful to consider orthogonal elements. Armstrong's apparent archetype is only one popular assemblage of the elements.
Rees, "JAR on Object Oriented"6, takes the orthogonal, or chinese-menu approach of definition and slyly notes that the Simula-style OOP is impoverished, yet widely considered the definition7.
On c2.com, there is a lovely concept to bring in focus the meaning of OO: "that an expression in a program, consisting of a function identifier and one or more arguments, can stand for multiple implementations." Similarly, "the basic idiom is to identify an object and then act upon it,"8 though that excludes multi-dispatch.
There seems to be a conflict between two camps: the v-table crowd (C++/Java) which tends to be reactionary ("that's not OO!"), and the crowd with wider experience (e.g. CLOS) that sees the v-table style as a special, and impoverished case. In the professional community, the v-table crowd dominates to the point of exclusion.
So, while there is some support of the taxonomies I prefer (cf. "wider" above), nobody will understand me if I use it. I'll have to use the popular definitions and complicate the explanation by qualifications and exceptions. And, probably have side-bars to explain multi-methods, etc.
I haven't found a good entre into the academic discourse, nor do I want to read pointless, hyperfocused papers on irrelevant minutiae.
[1] An essay on managing capability-security-model graphs when trying to share data: e.g. the file-system. Aka "Deep Attenuation."[2] I thought I had identified all the orthogonal pieces of OO.
[3] Name change claimed by http://c2.com/cgi/wiki?ObjectCapabilityModel as of 2009.03.03
[4] Cf. the dualism of single-dispatch vs generics and monkey-patching...
[5] See http://wiki.gsi.de/pub/Personalpages/RootTips/RClasses_2.ppt, and http://portal.acm.org/citation.cfm?id=1113040.
[6] See http://mumble.net/~jar/articles/oo.html
[7] If you only know Simula-style OOP, you are hereby required to prefix all of your mentions of OO with "Simula-style" or "v-table hack style."
[8] The author of that statement intended it to contradict the previous quote, but I see them as equivalent: "coherent objects that interact .... The rest is stylistic elaboration." http://c2.com/cgi/wiki?DiscussAlternateObjectOrientedProgrammingView, as of 2009.02.15
References http://en.wikipedia.org/wiki/Object-oriented_programming