

Objects Are Not Abstract Data Types - liebke
http://stuartsierra.com/2009/12/14/objects-are-not-adts

======
BigZaphod
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.

~~~
tumult
See also:

Modules in OCaml

Type classes in Haskell

C++0x "concepts" (axed from the specification, but you can do generic
programming with templates)

And many more.

------
dnewcome
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'.

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

------
artsrc
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.

------
keefe
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...

~~~
cstejerean
"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.

~~~
keefe
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.

------
kqr2
Here's the CLU language home page:

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

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

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

~~~
artsrc
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.

------
Miky
What Clojure's getting reminds me of Haskell.

