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.
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'.
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.
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...
"an object is a particular piece of memory, structured according to a class" does not sound like a particularly useful way to think about objects unless you are working at a low enough level that you care how objects are laid out in memory.
I don't particularly care how it's laid out. The point is that it is an instance of a class, which maintains its own local state - I don't care how that state is organized, but it's crucial to remember that it has such state.
I thought Clojure was duck typed, so I thought it would not require extra boiler plate.
Consider a max function that returns the largest of two entities by using a "compare" function.
In Python/C++ Templates you must:
1. Have a compare method in your class
2. Call compare in max.
In Go you must:
1. Have a compare method for your type
2. Call compare in max.
3. Define a Go interface 'Comparable' with the compare function
4. Declare the args to max to be of type Comparable
In Java (OO Style) you must:
1. Have a compare method in your class
2. Call compare in max.
3. Define an interface Comparable to have a compare method
4. Declare max to take type Comparable
5. Declare that your class, with the comparable method implements Comparable.
