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.
Objects Are Not Abstract Data Types
11–15 of 15 posts
Re: Objects Are Not Abstract Data Types
#12Re: Objects Are Not Abstract Data Types
#13So "protocols" are basically operations that can be performed on a data type? I don't get it.
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
#14Re: Objects Are Not Abstract Data Types
#15my 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.