Live data from Hacker News

Objects Are Not Abstract Data Types

stuartsierra.com

11–15 of 15 posts

Re: Objects Are Not Abstract Data Types

#11
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.

Re: Objects Are Not Abstract Data Types

#13
post #12

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

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.

Re: Objects Are Not Abstract Data Types

#14
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'.

Re: Objects Are Not Abstract Data Types

#15
post #5

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 ar…

"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.
Post reply on HN