Let me say that I like your overall presentation (despite my having said that it was "wrong or confused"). You have good content, you are just a little fuzzy on the object-oriented side and using terms like "abstract data type" too loosely.
Here is one of their final statements
We are now in complete agreement. I have discussed with Peter and we will change the book according to your recommendations, i.e. make clear the concepts: data abstraction, ADTs and objects, and the differences between objects and ADTs.
I have skimmed a lot of your book and studied the sections discussed below in some detail.
Pages 240-255:
You are using the term "abstract data type" in a dynamic
language, and this doesn't make very much sense. The
original idea of a user-defined abstract data type is that
one can define a new type that works just like the built-in
types "integer", "char" in Pascal. The idea is that the
type is abstract in that the implementation is hidden.
Now I agree that your idea of "secure abstract data type" is
in effect very similar to the traditional ADT in, for
example, CLU. But it bothers me that the "type", which is a
key part of the "abstract data type" concept is not
explicit. You are not using "type abstraction" to enforce
representation hiding. The commonly-accepted analysis of
this form of abstraction is with existential types (see
ADT1 or
ADT2
for example)
Instead, you have created a form of "abstract data value"
that can only be operated upon via the associated
operations.
Basically I think that you should replace the word "abstract
data type" with the word "data abstraction" everywhere. Then
things would make much more sense. What you are talking
about is various forms of data abstraction. Abstract data
types are one very specific kind of data abstraction.
p 470-481
I actually like the basic idea behind this discussion. I
hadn't read it when I started critiquing the OOP chapter.
However, there are some issues hidden here that are
important.
Most of the content in this section should be in the
object-oriented chapter if you ask me. Your development of
"bundled" data abstractions is basically an explication of
objects.
I think the most important one is hinted at in your comment
on page 474: "This version is secure, declarative, and
bundled. Note that it does not use wrapping, since wrapping
is only needed for unbundled ADTs."
This is one of the key difference between objects and
ADTs: objects don't need type abstraction or any kind of
explicit data hiding. Instead, objects use procedural
abstraction alone. This calls into question the
orthogonality of your attributes: In particular,
bundled+open doesn't make sense.
To me, the difference between unbundled and bundled is the
difference between ADTs and Objects. Either ADTs or Objects
can be declarative or state-based. The open/secure
distinction is not interesting because objects are always
secure, and ADTs are only really useful if they are secure.
As a result, I would say that Figure 6.2 incorrectly
classifies {Secure, Stateful, Unbundled} as a "unbundled
variant of the object-oriented style". Instead, it is simply
the normal stateful ADT.
The section "comparing two popular versions" should be
better.
I don't agree that "The implementations of both versions
have to do actions when entering and exiting an operation.
The calls of Unwrap and Wrap correspond to calls of @ and:=, respectively."
The interface for the stateful bundled version is not
clear. You should not list Push Pop and Empty as operations,
since they are methods. The type should be
This is the clearest illustration that this object version
is not an ADT. The type of the return value is completely
visible; it is not an abstract type <Stack T>. Note that
declarative bundled versions require recursive types.
It is very telling that you completely miss a very important
difference between the two versions: this is that anybody
can create their own implementation of stack in the object
paradigm, and all these dif
I just looked at the section on Object-Oriented programming. I haven't read much of it, but just about everything I have read is wrong or confused. They continue this common misconception that objects are a form of ADT (abstract data type) and the inheritance is the only important concept in object-oriented programming. Some examples of their confusion:
"We can loosely define object-oriented programming as programming with encapsulation, explicit state, and inheritance."
On inheritance: "... stateful abstract data types are a very useful concept for organizing a program. In fact, a program can be built in a hierarchical structure as ADTs that depend on other ADTs. This is the idea of component-based programming." and "Inheritance is the essential difference between object-oriented programming and
most other kinds of stateful programming."
"In the most general case, a class is an incremental definition of an ADT, that defines the ADT as a modification of other ADTs. There is a rich set of concepts for defining classes. We classify these concepts into two sets, according as they permit the class to define an ADT completely or incrementally:
*Complete ADT definition*...
-Defining the various elements that make up a class (Section 7.2.3), namely methods, attributes, and properties....
-Taking advantage of dynamic typing. This gives first-class messages Section 7.2.5) and first-class attributes (Section 7.2.6). This allows powerful forms of polymorphism that are difficult or impossible to do in statically-typed languages....
*Incremental ADT definition* These are all the concepts related to inheritance, that is, they define how a class is related to existing classes."
As far as I can tell the entire presentation is completely muddled. If people are interested I can give references and more detailed discussion for their confusion. For example, they don't seem to understand the difference between subtyping and inheritance (extends and implements in Java). If I get time, I will write to the authors to complain. But there is probably nothing that can be done about it before publication at this point.
Slashdot Mirror
This is the point I think people are missing. It's not just the technical details that are killing CORBA, its the fundamental assumption that transparent distributed objects are a good idea. I wrote an academic paper on this.. the conclusions will be no surprise to experts... but I'm trying to explain and quantify the issues: Web Services versus Distributed Objects: A Case Study of Performance and Interface Design William R. Cook, Janel Barfield To appear, Proc. of the IEEE International Conference on Web Services ( ICWS) 2006. September 18-22, Chicago, USA
Link ==> Discussion on Concepts, Techniques and Models of Computer Programming
Here is my conclusion from the disucssion:
Here is one of their final statementsYou are using the term "abstract data type" in a dynamic language, and this doesn't make very much sense. The original idea of a user-defined abstract data type is that one can define a new type that works just like the built-in types "integer", "char" in Pascal. The idea is that the type is abstract in that the implementation is hidden.
Now I agree that your idea of "secure abstract data type" is in effect very similar to the traditional ADT in, for example, CLU. But it bothers me that the "type", which is a key part of the "abstract data type" concept is not explicit. You are not using "type abstraction" to enforce representation hiding. The commonly-accepted analysis of this form of abstraction is with existential types (see ADT1 or ADT2 for example)
Instead, you have created a form of "abstract data value" that can only be operated upon via the associated operations.
Basically I think that you should replace the word "abstract data type" with the word "data abstraction" everywhere. Then things would make much more sense. What you are talking about is various forms of data abstraction. Abstract data types are one very specific kind of data abstraction.
p 470-481
I actually like the basic idea behind this discussion. I hadn't read it when I started critiquing the OOP chapter. However, there are some issues hidden here that are important.
Most of the content in this section should be in the object-oriented chapter if you ask me. Your development of "bundled" data abstractions is basically an explication of objects.
I think the most important one is hinted at in your comment on page 474: "This version is secure, declarative, and bundled. Note that it does not use wrapping, since wrapping is only needed for unbundled ADTs."
This is one of the key difference between objects and ADTs: objects don't need type abstraction or any kind of explicit data hiding. Instead, objects use procedural abstraction alone. This calls into question the orthogonality of your attributes: In particular, bundled+open doesn't make sense.
To me, the difference between unbundled and bundled is the difference between ADTs and Objects. Either ADTs or Objects can be declarative or state-based. The open/secure distinction is not interesting because objects are always secure, and ADTs are only really useful if they are secure.
As a result, I would say that Figure 6.2 incorrectly classifies {Secure, Stateful, Unbundled} as a "unbundled variant of the object-oriented style". Instead, it is simply the normal stateful ADT.
The section "comparing two popular versions" should be better.
This is the clearest illustration that this object version is not an ADT. The type of the return value is completely visible; it is not an abstract type <Stack T>. Note that declarative bundled versions require recursive types.
It is very telling that you completely miss a very important difference between the two versions: this is that anybody can create their own implementation of stack in the object paradigm, and all these dif
I just looked at the section on Object-Oriented programming. I haven't read much of it, but just about everything I have read is wrong or confused. They continue this common misconception that objects are a form of ADT (abstract data type) and the inheritance is the only important concept in object-oriented programming. Some examples of their confusion: "We can loosely define object-oriented programming as programming with encapsulation, explicit state, and inheritance." On inheritance: "... stateful abstract data types are a very useful concept for organizing a program. In fact, a program can be built in a hierarchical structure as ADTs that depend on other ADTs. This is the idea of component-based programming." and "Inheritance is the essential difference between object-oriented programming and most other kinds of stateful programming." "In the most general case, a class is an incremental definition of an ADT, that defines the ADT as a modification of other ADTs. There is a rich set of concepts for defining classes. We classify these concepts into two sets, according as they permit the class to define an ADT completely or incrementally: *Complete ADT definition*... -Defining the various elements that make up a class (Section 7.2.3), namely methods, attributes, and properties. ...
-Taking advantage of dynamic typing. This gives first-class messages Section 7.2.5) and first-class attributes (Section 7.2.6). This allows powerful forms of polymorphism that are difficult or impossible to do in statically-typed languages. ...
*Incremental ADT definition* These are all the concepts related to inheritance, that is, they define how a class is related to existing classes."
As far as I can tell the entire presentation is completely muddled. If people are interested I can give references and more detailed discussion for their confusion. For example, they don't seem to understand the difference between subtyping and inheritance (extends and implements in Java). If I get time, I will write to the authors to complain. But there is probably nothing that can be done about it before publication at this point.