Objects Are Not Abstract Data Types (opens in new tab)

my understanding is an object is a particular piece of memory, structured according to a class which may be seen as the abstract data type for that particular piece of data. As far as I understand the JVM, the compiler doesn't replicate function bodies for every instance of a class. I think a more appropriate title to this article would be... "protocols and datatypes in clojure", of course I wouldn't have read the article if that were the title...

I might be wrong, but doesn't this describe Google Go's interfaces as well? As in, the data structure of an object is independent of the functions/methods that can operate on the object. At least that's how I understand it right now (having never used it). And the type of a thing is related to the set of functions (matched by name) that are expected to work rather than the data's memory structure.

So "protocols" are basically operations that can be performed on a data type? I don't get it.

This article is too loose in throwing around terms. I'm pretty sure the title should be 'Classes Are Not Abstract Data Types'. An 'object' in the OO sense is a separate (albeit related) concept from a 'type' (class). OO is about behavior, not data. If that behavior is tied to an implementation, that is more of a design fault in the program than the language. We have always had abstract classes in c++, and we have interfaces in Java/.NET. The idea of separating the interface from the implementation is not something that we have been overlooking for the past 30 years as the author indicates. Maybe I'm missing something, but having the ability to define the data of a type separately from the behavior seems like a step back toward c structs with static methods to operate on them. The only difference is that you can group your methods into what should probably just be a class rather than a 'protocol'.

Also see "On Understanding Data Abstractions, Revisted": http://news.ycombinator.com/item?id=917065

A long time ago it was proven than a number of different abstract notions of computers could all solve the same set of problems.

We now have a number of different ways of articulating abstractions in source code. I suspect there is a mechanical way to transform a design using ADT's to a design using OO with the same dependency graph. We need to characterize the canonical abstraction in the same way we characterize a turing machine.

Here's the CLU language home page:

http://www.pmg.lcs.mit.edu/CLU.html

Objects aren't abstract data types because an object contains all of the methods to operate on the ADT in the same place.

What Clojure's getting reminds me of Haskell.