We agree with you completely.
But please do not read chapter 7 out of context.
The book is a complete story that is being
built successively.
Encapsulated state and what you call polymorphism
are actually covered, but not in this chapter.
In fact inheritance creates more complication in
the sense that makes necessary the introduction
of many other concepts that is being covered in
this chapter (Chapter 7).
Encapsulated state is all over the book. In particular Chapter 5 already introduces a simple concurrent form of objects that communicate with
'real' message sending. Chapter 6 talks about
encapsulated explicit state and many ways to build such entities.
In chapter 7 we constrast the functional view to the object-oriented view which really implies pholymorphism in the sense that related categories of objects accepts the same message but execute it in its specialled way. This is contrast to the case-analysis on type that has to
be done in the functional view.
Still all of these things are minor things in our book. The intension is a firm understanding and the relationship between different programming models, and Finally we have an extensive treatment of concurrent and distributed programming models (Chapters 4, 5, part of 7 on active objects, 8, and the chapter 11 on distributed programming)
All these are done with working programs and no handwaving.
--- Seif
Hello,
I would like to complement Peter's message at
a higher level.
First we are very happy that a lot of people
appreciate the book. Also we are open to all critique and
would like very much to improve the material further.
About the chapter of object-oriented programming.
The whole idea of the book to try to give a deeper
understanding of the relationship between different programming models. To make clear how different models augment each other. What is the distinctive feature of each extension.
We also wanted to introduce concepts as early as possible when the programming model is expressive
enough to warrent the introduction.
In this view the idea of abstract datatypes/interfaces were introduced already in the
declarative programming chapter and continued to
be important in the message-passing and
encapsulated-state/component programming chapter.
There of course pholymorphism is important,
among other things (invariants/post/preconditions)
The chapter of object oriented programming therefore cannot be read out of this context.
There we want to address what is distinctive of
this model which is basically inheritance. We
wanted the reader to understand the consequence
of inhertance and the other concepts that has
to come with it, like self, visibility of methods, etc. We also wanted to stress on the relationship
to other models. For example how usual programming
techniques of higher order programming can be modeled in oop, what higher order programming
can add to oop, and where oop gives other but equivalent techniques to other models
As we said in the beginning of this chapter we
scratch the surface of oop. but taken together
with other models we get a very rich programming
paradigm.
Finally I would like to stress that the book covers very well many aspects of concurrent programming which is very important for many industrial systems, e.g. building telecom systems. We cover
most of the aspects of concurrent oop, see active objects and shared-state concurrency.
---- Seif Haridi
Slashdot Mirror
We agree with you completely. But please do not read chapter 7 out of context. The book is a complete story that is being built successively. Encapsulated state and what you call polymorphism are actually covered, but not in this chapter. In fact inheritance creates more complication in the sense that makes necessary the introduction of many other concepts that is being covered in this chapter (Chapter 7). Encapsulated state is all over the book. In particular Chapter 5 already introduces a simple concurrent form of objects that communicate with 'real' message sending. Chapter 6 talks about encapsulated explicit state and many ways to build such entities. In chapter 7 we constrast the functional view to the object-oriented view which really implies pholymorphism in the sense that related categories of objects accepts the same message but execute it in its specialled way. This is contrast to the case-analysis on type that has to be done in the functional view. Still all of these things are minor things in our book. The intension is a firm understanding and the relationship between different programming models, and Finally we have an extensive treatment of concurrent and distributed programming models (Chapters 4, 5, part of 7 on active objects, 8, and the chapter 11 on distributed programming) All these are done with working programs and no handwaving. --- Seif
Commenting on the consumer would quickly exhaut memory. You are quite right. This issue is addressed in Chapter 4 of declarative concurrency. --- Seif
Hello, I would like to complement Peter's message at a higher level. First we are very happy that a lot of people appreciate the book. Also we are open to all critique and would like very much to improve the material further. About the chapter of object-oriented programming. The whole idea of the book to try to give a deeper understanding of the relationship between different programming models. To make clear how different models augment each other. What is the distinctive feature of each extension. We also wanted to introduce concepts as early as possible when the programming model is expressive enough to warrent the introduction. In this view the idea of abstract datatypes/interfaces were introduced already in the declarative programming chapter and continued to be important in the message-passing and encapsulated-state/component programming chapter. There of course pholymorphism is important, among other things (invariants/post/preconditions) The chapter of object oriented programming therefore cannot be read out of this context. There we want to address what is distinctive of this model which is basically inheritance. We wanted the reader to understand the consequence of inhertance and the other concepts that has to come with it, like self, visibility of methods, etc. We also wanted to stress on the relationship to other models. For example how usual programming techniques of higher order programming can be modeled in oop, what higher order programming can add to oop, and where oop gives other but equivalent techniques to other models As we said in the beginning of this chapter we scratch the surface of oop. but taken together with other models we get a very rich programming paradigm. Finally I would like to stress that the book covers very well many aspects of concurrent programming which is very important for many industrial systems, e.g. building telecom systems. We cover most of the aspects of concurrent oop, see active objects and shared-state concurrency. ---- Seif Haridi