Followups set to comp.object; apologies for disturbing comp.lang.forth
readers, but this seems to have a sideline into that direction as well.


I've been trying my hand in programming Java for a while now, but have
failed to see the "big" difference of what is procedural and what is OO
programming until very recently (or this is how I currently feel). I'm
inviting comments on whether or not I finally have the correct idea. My
background is mostly from procedural languages with or without objects
(mostly C, perl), but I've occasionally tried to understand Smalltalk
as well as Forth. In Java I've mostly been limited to server-side Java
(servlets, with an occasional touch of EJBs).

Now, to the thought that occurred to me: in Java, much of the code is
actually not real OO code, but procerdural code that utilises objects.
Still, it would in many places be possible to write Java in more rigid
OO fashion. This'd explain my perplexion in not seeing that much
difference with what I consider "good" perl code and with Java.

Contrasting Java with Smalltalk: in Java, it seems common to write
methods to very procedural form (no return values on methods, lots
of branching constructs). With Smalltalk, it seems that pretty much
all methods have made some selection on which object type to return.
Additionally, methods tend to be very short (esp. comparing to some Java
servlet code I've seen).

The Smalltalk style appears to me to be build on very long (Contrasting
to Java) message chains, which begin by building some new object, then
doing numerous pieces of small-scale processing on that object (and in
the end perhaps/often returning a completely different object than was
originally created). I think I've seen a reference to "message-passing
OO" somewhere.

What I often see with Java is that a single statement contains just
a single method call - and for the cases where the method returns
something, the return value is stored to a variable, to be used
perhaps once or twice later on. So, in many cases, code very similar
to the Smalltalk messaging would be possible, but is not done. This
is the issue that seems odd to me; is this just a cultural issue
(Java programmers largely having a strong background in procedural
programming, and the paradigm shift is not happening), or are there
technical issues somewhere in the history of Java?

Further, in the Smalltalk code it seems that actual branches are not
very common, instead behaviour differences come from very heavy use of
polymorphism (which seems to be much less often used in Java). Again,
is this just a culture issue? Or is the whole issue that the Java code
I've seen is just procedurally written crap - that in "real life" (for
some value thereof..) Java code resembles much more my representation of
Smalltalk?

So, summarizing; what I feel is non-OO in the way I see Java code written:
- many methods written to return no value (void)
- if/else constructs used instead of object polymorphism to achieve
  differences in program behaviour
- a lot of avoidable local variables used (references to which could then
  be accidentally leaked somewhere, and thus be ineligible for garbage
  collection)

This still leaves me to think about the need of exceptions in OO code:
I think exceptions have their place, but are often misused in Java.
My experience with Smalltalk doesn't yet cover exception use, so cannot
make any comparisions on this (does Smalltalk even have exceptions?).

.... and a further question: is "message-passing OO" as used in Smalltalk
the only form of object-oriented programming, or are there other variants
of "pure OO" (as in "not tainted by procedural programming")?


Finally to the sideline to Forth. I seem to see strong resemblance of
Forth idea of threading small pieces of code to modify a set of data
to the Smalltalk object-message style of programming -- just that the
"raw" data of the Forth program is presented as objects in Smalltalk.
Am I just seeing ghosts here, or do these two share some conceptual
similarity?


And thanks goes to anyone for shedding any light on this all-too-long
rambling - but I seriously need handholding to get my thoughts on this
to any sensible shape.
-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Juha Laiho wrote:

> Followups set to comp.object; apologies for disturbing comp.lang.forth
> readers, but this seems to have a sideline into that direction as well.
> 
> 
> I've been trying my hand in programming Java for a while now, but have
> failed to see the "big" difference of what is procedural and what is OO
> programming until very recently (or this is how I currently feel). I'm
> inviting comments on whether or not I finally have the correct idea. My
> background is mostly from procedural languages with or without objects
> (mostly C, perl), but I've occasionally tried to understand Smalltalk
> as well as Forth. In Java I've mostly been limited to server-side Java
> (servlets, with an occasional touch of EJBs).
> 
> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises objects.
> Still, it would in many places be possible to write Java in more rigid
> OO fashion.

Jaho,

The distinction between procedural and 'rigid' OO is artificial. In an 
OO language, you have the additional ability to dispatch (bind method 
implementations to calls) on the class of an argument of the call, 
usually only the first one (as in Java and Smalltalk). Smalltalk and 
Java are just as imperative as C or Pascal.

A more influential (on coding style) difference between Smalltalk and 
Java is that, while both are strongly typed (Smalltalk more strongly as 
it doesn't have casts), Smalltalk is dynamically typed, while Java is 
statically typed.

This means that in Smalltalk you can send any message (call a method 
with any name) to any object, and the compiler won't complain, and your 
message will be sent. If no matching method for a sent message exists 
yet, you have the chance to define it and resume as if the method 
already existed, or alternatively, implement code to deal specifically 
with the situation that no matching method is found. You can also resume 
from there. Smalltalk implementations typically have a very flexible and 
powerful exception mechanism that works to enable and control this. (BTW 
this type of edit-and-continue can be provided for statically typed 
languages too, by implementing a mechanism like the one Smalltalk has 
natively, in the IDE).

Another important reason for differing coding styles is that typical 
Smalltalk development is image-based and the image already contains 
implementations for a great deal of the logic you need to have available 
for most problems you encounter as a programmer. This image full of code 
is also very easily and powerfully searchable. This leads to 
Smalltalkers studying the image for clues and solutions, much more than 
studying library documentation. As a consequence, they see a lot of code 
that is written in many-small-methods style, and they often follow that 
style.

[Advantages of many-small-methods are the ability to attach (method) 
names to smaller pieces of code, so that the names are more explanatory, 
and it allows finer-grained redefinition in subclasses, so you have less 
code duplication. These advantages no doubt help to perpetuate the use 
of a many-small-methods coding style.]

A third important influence on coding style in Smalltalk is the fact 
that Smalltalk has anonymous functions which act as closures (meaning 
that they can remember the context in which they were activated, and are 
able to read, and write to, any variable visible from that context). 
These things are called "blocks" in Smalltalk and there is very 
convenient syntax for them (Lisp has them too, but there is no special 
syntax for them - but Lisp has other mechanisms to counter that).

The availability of blocks means that Smalltalk does not need any syntax 
for control structures, and consequently most Smalltalks don't have them 
(nor any reserved words for that matter).

There are other factors than the ones you mention, and the ones you 
mention are certainly influences as well, but I hope I have highlighted 
some factors that would not be immediately obvious to a beginning 
Smalltalker.

Cheers,

Peter

 > This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.
> 
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some Java
> servlet code I've seen).
> 
> The Smalltalk style appears to me to be build on very long (Contrasting
> to Java) message chains, which begin by building some new object, then
> doing numerous pieces of small-scale processing on that object (and in
> the end perhaps/often returning a completely different object than was
> originally created). I think I've seen a reference to "message-passing
> OO" somewhere.
> 
> What I often see with Java is that a single statement contains just
> a single method call - and for the cases where the method returns
> something, the return value is stored to a variable, to be used
> perhaps once or twice later on. So, in many cases, code very similar
> to the Smalltalk messaging would be possible, but is not done. This
> is the issue that seems odd to me; is this just a cultural issue
> (Java programmers largely having a strong background in procedural
> programming, and the paradigm shift is not happening), or are there
> technical issues somewhere in the history of Java?
> 
> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java code
> I've seen is just procedurally written crap - that in "real life" (for
> some value thereof..) Java code resembles much more my representation of
> Smalltalk?
> 
> So, summarizing; what I feel is non-OO in the way I see Java code written:
> - many methods written to return no value (void)
> - if/else constructs used instead of object polymorphism to achieve
>   differences in program behaviour
> - a lot of avoidable local variables used (references to which could then
>   be accidentally leaked somewhere, and thus be ineligible for garbage
>   collection)
> 
> This still leaves me to think about the need of exceptions in OO code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).
> 
> .... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other variants
> of "pure OO" (as in "not tainted by procedural programming")?
> 
> 
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data
> to the Smalltalk object-message style of programming -- just that the
> "raw" data of the Forth program is presented as objects in Smalltalk.
> Am I just seeing ghosts here, or do these two share some conceptual
> similarity?
> 
> 
> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on this
> to any sensible shape.

The difference between OO and procedural (at least according to Nygaard
who invented OOP) is not in the actual code written, but in how the
program design is modeled.

In procedural programming, a program is designed as a collection of
processes and tasks which are applied in sequence, perhaps passing a set
of data from one to the other.  In OO programs, the program structure is
defined in terms of collections of agents (objects) that collaborate to
accomplish a purpose, and the collaboration takes place via the exchange
of messages.

Perhaps the most important difference between the two is that a structural
program represents a functional decomposition of an application where each
"unit" in the program supports or implements a specific "task".

In OO, we use a recursive decomposition (described originally by Alan Kay)
which can be thought of as opening up a computer and discovering that its
"innards" is a collection of little computers, each with the same
computational capabilities as the original computer.  Then if one were to
open up one of this litte computer, there would be a collection of even
little-er computers, each of which would have.... ad infinitum.

The implementation of these models always requires some sort of procedural
programming, in the body of a class's methods for example.  From a
strictly practical point of view, we can't get away from some level of
procedural programming because our code has to map to similar underlying
processor instruction sets.

it is my opinion that historically, the OO languages we use tend to be
derived from the more successful procedural languages ("and in those days,
C begat C++ which begat Java").  There are some interesting OO
implementations that are based on non-procedural languages, some of which
are no longer in public circulation (Zetlisp comes to mind) but which are
based on other programming models and languages like Prolog and Lisp.

I have the opportunity to examine so called OO code written in both Java
and C++ in the public and private sectors.  I am of the sad opinion that
many of the current generation of programmers who have started off their
programming careers with "internet" programming could not write a decent
procedure to save their life (i.e. method body).

On Sat, 12 Feb 2005 19:53:17 +0000, Juha Laiho wrote:

> Followups set to comp.object; apologies for disturbing comp.lang.forth
> readers, but this seems to have a sideline into that direction as well.
> 
> 
> I've been trying my hand in programming Java for a while now, but have
> failed to see the "big" difference of what is procedural and what is OO
> programming until very recently (or this is how I currently feel). I'm
> inviting comments on whether or not I finally have the correct idea. My
> background is mostly from procedural languages with or without objects
> (mostly C, perl), but I've occasionally tried to understand Smalltalk as
> well as Forth. In Java I've mostly been limited to server-side Java
> (servlets, with an occasional touch of EJBs).
> 
> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises objects.
> Still, it would in many places be possible to write Java in more rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.
> 
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots of
> branching constructs). With Smalltalk, it seems that pretty much all
> methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some Java
> servlet code I've seen).
> 
> The Smalltalk style appears to me to be build on very long (Contrasting
> to Java) message chains, which begin by building some new object, then
> doing numerous pieces of small-scale processing on that object (and in
> the end perhaps/often returning a completely different object than was
> originally created). I think I've seen a reference to "message-passing
> OO" somewhere.
> 
> What I often see with Java is that a single statement contains just a
> single method call - and for the cases where the method returns
> something, the return value is stored to a variable, to be used perhaps
> once or twice later on. So, in many cases, code very similar to the
> Smalltalk messaging would be possible, but is not done. This is the
> issue that seems odd to me; is this just a cultural issue (Java
> programmers largely having a strong background in procedural
> programming, and the paradigm shift is not happening), or are there
> technical issues somewhere in the history of Java?
> 
> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use of
> polymorphism (which seems to be much less often used in Java). Again, is
> this just a culture issue? Or is the whole issue that the Java code I've
> seen is just procedurally written crap - that in "real life" (for some
> value thereof..) Java code resembles much more my representation of
> Smalltalk?
> 
> So, summarizing; what I feel is non-OO in the way I see Java code
> written: - many methods written to return no value (void) - if/else
> constructs used instead of object polymorphism to achieve
>   differences in program behaviour
> - a lot of avoidable local variables used (references to which could
> then
>   be accidentally leaked somewhere, and thus be ineligible for garbage
>   collection)
> 
> This still leaves me to think about the need of exceptions in OO code: I
> think exceptions have their place, but are often misused in Java. My
> experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).
> 
> ... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other
> variants of "pure OO" (as in "not tainted by procedural programming")?
> 
> 
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data to
> the Smalltalk object-message style of programming -- just that the "raw"
> data of the Forth program is presented as objects in Smalltalk. Am I
> just seeing ghosts here, or do these two share some conceptual
> similarity?
> 
> 
> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on this
> to any sensible shape.

-- 
..................................................
It was all so different before everything changed.

Rod Davison -  Critical Knowledge Systems Inc. 

On Sun, 13 Feb 2005 00:24:43 +0100, Peter van Rooijen wrote:

>  This image full of code  is also very easily and powerfully searchable.
>  This leads to Smalltalkers studying the image for clues and solutions,
>  much more than studying library documentation. As a consequence, they
>  see a lot of code that is written in many-small-methods style, and they
>  often follow that style.

I'd think another advantage is that the above makes it easier to
comprehend a large program.

It might be fun for you to look back at the "Design Principles Behind
Smalltalk"
http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

Juha Laiho wrote:

....
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data
> to the Smalltalk object-message style of programming -- just that the
> "raw" data of the Forth program is presented as objects in Smalltalk.
> Am I just seeing ghosts here, or do these two share some conceptual
> similarity?
> 
> 

I see that Forth and Smalltalk lead to some kind of stack based thinking.
With Java one might feel forced to think in terms of return values getting
bound to symbols for semantic purpose. 

Also Forth and Smalltalk lead to a 'Keep it simple' paradigm, because
"reuseability" is always in mind. Creating and defining "vocabularies" in
Forth has a lot of similarites to the OO concept of Smalltalk.

Shin

I'm a little hungover, so bare with me. Lol.

> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises objects.

OOP is basically objects of which have procedures, so for code to be OO 
doesn't mean it has to be devoid of procedural programming. Each object's 
method is a procedure, but the difference is that procedure is part of an 
object as opposed to just being a procedure sitting on it's own. The way OOP 
utilizes this is that each object is responsible for procedures that it can 
handle. For example, lets say I have a Patient object in a Servlet and I 
want to process some HTML describing that patient. With the patient object, 
I can have a simple DrawHTML procedure so that each patient can draw itself. 
To take this to another level, say I have a PatientList object which is a 
container of Patient objects. If I want to draw the entire list, I can 
fashion a drawHTML at the PatientList object (note: this is not 
polymorphism, it's aggregation) which then calls each Patient's DrawHTML 
method. So, to draw patients, I call PatientList's drawHTML method which 
then calls each Patient's drawHTML method. This way, I don't have to have a 
single procedure that is responsible for determining the list of patients to 
draw AND drawing each patient. This is beneficial if I want to change the 
list in any way. Say I want to draw a list of patients that start with the 
letter A: I just have to modify the PatientList drawHTML method which will 
not affect the patient's drawHTML method. It isolates the patient's drawHTML 
code so I don't have to worry about it. Furthermore, say I want multiple 
procedures in PatientList to draw patients: 1 for patients beginning with 
the letter A, one with a complete list of patients. I never have to change 
the patient's drawHTML code. Ofcourse, you can do this procedurally by 
having a drawPatientHTML(String name, String id, etc) but with OOP, I can 
just pass a Patient object. It's cleaner to have the patient draw itself in 
OOP.

> Still, it would in many places be possible to write Java in more rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.

Just because a language is OO, doesn't mean that it forces developers to 
code in an OO fashion. Java is VERY OO in the fact that everything is an 
object except simple data types, and they have associated objects as well 
(ie int and Integer obejct).

>
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some Java
> servlet code I've seen).

It's good procedural form to keep your methods short (typically I keep them 
under a "screen page") just so you don't get lost in the code. I was coding 
after someone who didn't quite understand this and had formed a very complex 
procedure to be around 16 "printer pages" and was very difficult to work 
with. Before refactoring a huge chunk of the app, I broke it down to more 
managable procedures that the main procedure called.

> The Smalltalk style appears to me to be build on very long (Contrasting
> to Java) message chains, which begin by building some new object, then
> doing numerous pieces of small-scale processing on that object (and in
> the end perhaps/often returning a completely different object than was
> originally created). I think I've seen a reference to "message-passing
> OO" somewhere.

I know absolutely nothing about SmallTalk, but this seems very strange to 
me. Are you talking about inheritance?

> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java code
> I've seen is just procedurally written crap - that in "real life" (for
> some value thereof..) Java code resembles much more my representation of
> Smalltalk?

I would say "procedurally written crap." All of the Java and Delphi code I 
write is heavily OO. I can't stand using procedural languages, but 
unfortunately in designing web apps, I have to use JS which is very 
procedural and not strongly type casted (which is another issue).

> So, summarizing; what I feel is non-OO in the way I see Java code written:
> - many methods written to return no value (void)

This doesn't have anything to do with OO/Procedural coding that I can think 
of. Lets say I want to add a Patient object to the PatientList. If I were 
storing the Patients in a HashMap and created an add(Patient pat) on the 
PatientList object, I would not need to return a variable in this method. If 
it was in an Array or ArrayList, I could return the index, but that is 
dependent on the container I'm using, not whether I'm using OO or procedural 
programming.

> - if/else constructs used instead of object polymorphism to achieve
>  differences in program behaviour

I'd have to see an example to determine if this is correct or not, but just 
like databases and normalization, sometimes it's better to denormalize just 
a bit to gain speed. In java, polymorphism might not be warranted if it's a 
simple if/else statement. But like I said, I'd need to see an example.

> - a lot of avoidable local variables used (references to which could then
>  be accidentally leaked somewhere, and thus be ineligible for garbage
>  collection)

You should always define variables in the lowest scope possible. There is 
nothing wrong with local variabes, on the contrary, it's bad form to have a 
bunch of global variables, but you will probably always have them, just try 
to keep them to a minimum. For example, in a servlet, I keep my DB 
connection/pool in a global scope in the servletContext. It doesn't make 
sense to create them locally.

> This still leaves me to think about the need of exceptions in OO code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).

Exceptions are very useful in any type of programming, it keeps your program 
from "farting" at the user. You trap the exception, handle it gracefully if 
possible, and the user doesn't know any different. For example, lets say you 
have an HTML form that requires some sort of number. Well, HTML isn't 
strongly typed, so it comes in as a string. What if they put "A" instead of 
a number. You could trap the exception and report to the user via HTML that 
"A number is required," or you could just let your servlet crash. I'd say 
most would prefer the former. Lol.

> ... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other variants
> of "pure OO" (as in "not tainted by procedural programming")?

I'm not sure what message-passing OO is, but a good book on OOP is C++: The 
Core Language. It goes through OOP very well.

> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on this
> to any sensible shape.

You're welcome. Sorry I couldn't help you with your Smalltalk and Forth 
comparisons though. Wish me luck on my hangover. Lol.

---
Tom Dyess
OraclePower.com 

"Juha Laiho" <Juha.Laiho@iki.fi> wrote in message 
news:culmrd$d7e$1@ichaos.ichaos-int...
> Followups set to comp.object; apologies for disturbing comp.lang.forth
> readers, but this seems to have a sideline into that direction as well.
>
>
> I've been trying my hand in programming Java for a while now, but have
> failed to see the "big" difference of what is procedural and what is OO
> programming until very recently (or this is how I currently feel). I'm
> inviting comments on whether or not I finally have the correct idea. My
> background is mostly from procedural languages with or without objects
> (mostly C, perl), but I've occasionally tried to understand Smalltalk
> as well as Forth. In Java I've mostly been limited to server-side Java
> (servlets, with an occasional touch of EJBs).
>
> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises objects.
> Still, it would in many places be possible to write Java in more rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.
>
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some Java
> servlet code I've seen).
>
> The Smalltalk style appears to me to be build on very long (Contrasting
> to Java) message chains, which begin by building some new object, then
> doing numerous pieces of small-scale processing on that object (and in
> the end perhaps/often returning a completely different object than was
> originally created). I think I've seen a reference to "message-passing
> OO" somewhere.
>
> What I often see with Java is that a single statement contains just
> a single method call - and for the cases where the method returns
> something, the return value is stored to a variable, to be used
> perhaps once or twice later on. So, in many cases, code very similar
> to the Smalltalk messaging would be possible, but is not done. This
> is the issue that seems odd to me; is this just a cultural issue
> (Java programmers largely having a strong background in procedural
> programming, and the paradigm shift is not happening), or are there
> technical issues somewhere in the history of Java?
>
> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java code
> I've seen is just procedurally written crap - that in "real life" (for
> some value thereof..) Java code resembles much more my representation of
> Smalltalk?
>
> So, summarizing; what I feel is non-OO in the way I see Java code written:
> - many methods written to return no value (void)
> - if/else constructs used instead of object polymorphism to achieve
>  differences in program behaviour
> - a lot of avoidable local variables used (references to which could then
>  be accidentally leaked somewhere, and thus be ineligible for garbage
>  collection)
>
> This still leaves me to think about the need of exceptions in OO code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).
>
> ... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other variants
> of "pure OO" (as in "not tainted by procedural programming")?
>
>
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data
> to the Smalltalk object-message style of programming -- just that the
> "raw" data of the Forth program is presented as objects in Smalltalk.
> Am I just seeing ghosts here, or do these two share some conceptual
> similarity?
>
>
> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on this
> to any sensible shape.
> -- 
> Wolf  a.k.a.  Juha Laiho     Espoo, Finland
> (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
>         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
> "...cancel my subscription to the resurrection!" (Jim Morrison) 

I'm a little hungover, so bare with me. Lol.

> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises objects.

OOP is basically objects of which have procedures, so for code to be OO
doesn't mean it has to be devoid of procedural programming. Each object's
method is a procedure, but the difference is that procedure is part of an
object as opposed to just being a procedure sitting on it's own. The way OOP
utilizes this is that each object is responsible for procedures that it can
handle. For example, lets say I have a Patient object in a Servlet and I
want to process some HTML describing that patient. With the patient object,
I can have a simple DrawHTML procedure so that each patient can draw itself.
To take this to another level, say I have a PatientList object which is a
container of Patient objects. If I want to draw the entire list, I can
fashion a drawHTML at the PatientList object (note: this is not
polymorphism, it's aggregation) which then calls each Patient's DrawHTML
method. So, to draw patients, I call PatientList's drawHTML method which
then calls each Patient's drawHTML method. This way, I don't have to have a
single procedure that is responsible for determining the list of patients to
draw AND drawing each patient. This is beneficial if I want to change the
list in any way. Say I want to draw a list of patients that start with the
letter A: I just have to modify the PatientList drawHTML method which will
not affect the patient's drawHTML method. It isolates the patient's drawHTML
code so I don't have to worry about it. Furthermore, say I want multiple
procedures in PatientList to draw patients: 1 for patients beginning with
the letter A, one with a complete list of patients. I never have to change
the patient's drawHTML code. Ofcourse, you can do this procedurally by
having a drawPatientHTML(String name, String id, etc) but with OOP, I can
just pass a Patient object. It's cleaner to have the patient draw itself in
OOP.

> Still, it would in many places be possible to write Java in more rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.

Just because a language is OO, doesn't mean that it forces developers to
code in an OO fashion. Java is VERY OO in the fact that everything is an
object except simple data types, and they have associated objects as well
(ie int and Integer obejct).

>
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some Java
> servlet code I've seen).

It's good procedural form to keep your methods short (typically I keep them
under a "screen page") just so you don't get lost in the code. I was coding
after someone who didn't quite understand this and had formed a very complex
procedure to be around 16 "printer pages" and was very difficult to work
with. Before refactoring a huge chunk of the app, I broke it down to more
managable procedures that the main procedure called.

> The Smalltalk style appears to me to be build on very long (Contrasting
> to Java) message chains, which begin by building some new object, then
> doing numerous pieces of small-scale processing on that object (and in
> the end perhaps/often returning a completely different object than was
> originally created). I think I've seen a reference to "message-passing
> OO" somewhere.

I know absolutely nothing about SmallTalk, but this seems very strange to
me. Are you talking about inheritance?

> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java code
> I've seen is just procedurally written crap - that in "real life" (for
> some value thereof..) Java code resembles much more my representation of
> Smalltalk?

I would say "procedurally written crap." All of the Java and Delphi code I
write is heavily OO. I can't stand using procedural languages, but
unfortunately in designing web apps, I have to use JS which is very
procedural and not strongly type casted (which is another issue).

> So, summarizing; what I feel is non-OO in the way I see Java code written:
> - many methods written to return no value (void)

This doesn't have anything to do with OO/Procedural coding that I can think
of. Lets say I want to add a Patient object to the PatientList. If I were
storing the Patients in a HashMap and created an add(Patient pat) on the
PatientList object, I would not need to return a variable in this method. If
it was in an Array or ArrayList, I could return the index, but that is
dependent on the container I'm using, not whether I'm using OO or procedural
programming.

> - if/else constructs used instead of object polymorphism to achieve
>  differences in program behaviour

I'd have to see an example to determine if this is correct or not, but just
like databases and normalization, sometimes it's better to denormalize just
a bit to gain speed. In java, polymorphism might not be warranted if it's a
simple if/else statement. But like I said, I'd need to see an example.

> - a lot of avoidable local variables used (references to which could then
>  be accidentally leaked somewhere, and thus be ineligible for garbage
>  collection)

You should always define variables in the lowest scope possible. There is
nothing wrong with local variabes, on the contrary, it's bad form to have a
bunch of global variables, but you will probably always have them, just try
to keep them to a minimum. For example, in a servlet, I keep my DB
connection/pool in a global scope in the servletContext. It doesn't make
sense to create them locally.

> This still leaves me to think about the need of exceptions in OO code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).

Exceptions are very useful in any type of programming, it keeps your program
from "farting" at the user. You trap the exception, handle it gracefully if
possible, and the user doesn't know any different. For example, lets say you
have an HTML form that requires some sort of number. Well, HTML isn't
strongly typed, so it comes in as a string. What if they put "A" instead of
a number. You could trap the exception and report to the user via HTML that
"A number is required," or you could just let your servlet crash. I'd say
most would prefer the former. Lol.

> ... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other variants
> of "pure OO" (as in "not tainted by procedural programming")?

I'm not sure what message-passing OO is, but a good book on OOP is C++: The
Core Language. It goes through OOP very well.

> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on this
> to any sensible shape.

You're welcome. Sorry I couldn't help you with your Smalltalk and Forth
comparisons though. Wish me luck on my hangover. Lol.

---
Tom Dyess
OraclePower.com

I'm a little hungover, so bare with me. Lol.

> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises objects.

OOP is basically objects of which have procedures, so for code to be OO
doesn't mean it has to be devoid of procedural programming. Each object's
method is a procedure, but the difference is that procedure is part of an
object as opposed to just being a procedure sitting on it's own. The way OOP
utilizes this is that each object is responsible for procedures that it can
handle. For example, lets say I have a Patient object in a Servlet and I
want to process some HTML describing that patient. With the patient object,
I can have a simple DrawHTML procedure so that each patient can draw itself.
To take this to another level, say I have a PatientList object which is a
container of Patient objects. If I want to draw the entire list, I can
fashion a drawHTML at the PatientList object (note: this is not
polymorphism, it's aggregation) which then calls each Patient's DrawHTML
method. So, to draw patients, I call PatientList's drawHTML method which
then calls each Patient's drawHTML method. This way, I don't have to have a
single procedure that is responsible for determining the list of patients to
draw AND drawing each patient. This is beneficial if I want to change the
list in any way. Say I want to draw a list of patients that start with the
letter A: I just have to modify the PatientList drawHTML method which will
not affect the patient's drawHTML method. It isolates the patient's drawHTML
code so I don't have to worry about it. Furthermore, say I want multiple
procedures in PatientList to draw patients: 1 for patients beginning with
the letter A, one with a complete list of patients. I never have to change
the patient's drawHTML code. Ofcourse, you can do this procedurally by
having a drawPatientHTML(String name, String id, etc) but with OOP, I can
just pass a Patient object. It's cleaner to have the patient draw itself in
OOP.

> Still, it would in many places be possible to write Java in more rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.

Just because a language is OO, doesn't mean that it forces developers to
code in an OO fashion. Java is VERY OO in the fact that everything is an
object except simple data types, and they have associated objects as well
(ie int and Integer obejct).

>
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some Java
> servlet code I've seen).

It's good procedural form to keep your methods short (typically I keep them
under a "screen page") just so you don't get lost in the code. I was coding
after someone who didn't quite understand this and had formed a very complex
procedure to be around 16 "printer pages" and was very difficult to work
with. Before refactoring a huge chunk of the app, I broke it down to more
managable procedures that the main procedure called.

> The Smalltalk style appears to me to be build on very long (Contrasting
> to Java) message chains, which begin by building some new object, then
> doing numerous pieces of small-scale processing on that object (and in
> the end perhaps/often returning a completely different object than was
> originally created). I think I've seen a reference to "message-passing
> OO" somewhere.

I know absolutely nothing about SmallTalk, but this seems very strange to
me. Are you talking about inheritance?

> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java code
> I've seen is just procedurally written crap - that in "real life" (for
> some value thereof..) Java code resembles much more my representation of
> Smalltalk?

I would say "procedurally written crap." All of the Java and Delphi code I
write is heavily OO. I can't stand using procedural languages, but
unfortunately in designing web apps, I have to use JS which is very
procedural and not strongly type casted (which is another issue).

> So, summarizing; what I feel is non-OO in the way I see Java code written:
> - many methods written to return no value (void)

This doesn't have anything to do with OO/Procedural coding that I can think
of. Lets say I want to add a Patient object to the PatientList. If I were
storing the Patients in a HashMap and created an add(Patient pat) on the
PatientList object, I would not need to return a variable in this method. If
it was in an Array or ArrayList, I could return the index, but that is
dependent on the container I'm using, not whether I'm using OO or procedural
programming.

> - if/else constructs used instead of object polymorphism to achieve
>  differences in program behaviour

I'd have to see an example to determine if this is correct or not, but just
like databases and normalization, sometimes it's better to denormalize just
a bit to gain speed. In java, polymorphism might not be warranted if it's a
simple if/else statement. But like I said, I'd need to see an example.

> - a lot of avoidable local variables used (references to which could then
>  be accidentally leaked somewhere, and thus be ineligible for garbage
>  collection)

You should always define variables in the lowest scope possible. There is
nothing wrong with local variabes, on the contrary, it's bad form to have a
bunch of global variables, but you will probably always have them, just try
to keep them to a minimum. For example, in a servlet, I keep my DB
connection/pool in a global scope in the servletContext. It doesn't make
sense to create them locally.

> This still leaves me to think about the need of exceptions in OO code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).

Exceptions are very useful in any type of programming, it keeps your program
from "farting" at the user. You trap the exception, handle it gracefully if
possible, and the user doesn't know any different. For example, lets say you
have an HTML form that requires some sort of number. Well, HTML isn't
strongly typed, so it comes in as a string. What if they put "A" instead of
a number. You could trap the exception and report to the user via HTML that
"A number is required," or you could just let your servlet crash. I'd say
most would prefer the former. Lol.

> ... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other variants
> of "pure OO" (as in "not tainted by procedural programming")?

I'm not sure what message-passing OO is, but a good book on OOP is C++: The
Core Language. It goes through OOP very well.

> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on this
> to any sensible shape.

You're welcome. Sorry I couldn't help you with your Smalltalk and Forth
comparisons though. Wish me luck on my hangover. Lol.

---
Tom Dyess
OraclePower.com

On Sun, 13 Feb 2005 00:24:43 +0100, Peter van Rooijen
<peter@vanrooijen.com> wrote:

>The distinction between procedural and 'rigid' OO is artificial.

Such distinction does not exist. Almost all OO languages (if not all)
are procedural.

<quote>

procedural language

<language> Any programming language in which the programmer specifies
an explicit sequences of steps to follow to produce a result. 

The term should not be confused with "imperative language". An example
(non-imperative) procedural language is LOGO, which specifies
sequences of steps to perform but does not have an internal state. 

Other procedural languages include Basic, Pascal, C, and Modula-2. 

Both these types of language are in contrast to declarative languages,
in which the programmer specifies neither explicit sequences of
actions nor internal state manipulation. 

</quote>

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=procedural+language&action=Search

>Smalltalk and 
>Java are just as imperative as C or Pascal.

And as procedural.

>This means that in Smalltalk you can send any message (call a method 
>with any name)

Or in other words: call a procedure.


Regards

On Sun, 13 Feb 2005 12:07:11 -0500, "Tom Dyess" <tdyess@dysr.com>
wrote:

>OOP is basically objects of which have procedures, so for code to be OO 
>doesn't mean it has to be devoid of procedural programming. Each object's 
>method is a procedure, but the difference is that procedure is part of an 
>object as opposed to just being a procedure sitting on it's own.

That procedure is part of a class.

But the word "object" is a wildcard that might mean anything "class"
inclued, so what you said is not incorrect. Everything is an object:
types, variables, values, procedures, programs, computers, users, etc.

One of the differences between OO languages and classic structured
languages is that procedures are bundled with types (classes). 

Which is a bad idea BTW.

>Just because a language is OO, doesn't mean that it forces developers to 
>code in an OO fashion. Java is VERY OO in the fact that everything is an 
>object except simple data types, and they have associated objects as well 
>(ie int and Integer obejct).

You probably mean that it is not possible to create procedures that
are not bundled with types. Which is a bad thing.

>I would say "procedurally written crap." All of the Java and Delphi code I 
>write is heavily OO.

And heavily procedural.

> I can't stand using procedural languages,

But Java and Delphi are procedural languages.

>This doesn't have anything to do with OO/Procedural coding that I can think 
>of. Lets say I want to add a Patient object to the PatientList. If I were 
>storing the Patients in a HashMap and created an add(Patient pat) on the 
>PatientList object, I would not need to return a variable in this method. If 
>it was in an Array or ArrayList, I could return the index, but that is 
>dependent on the container I'm using, not whether I'm using OO or procedural 
>programming.

That is a very primitive way to manage data.


Regards

On Sun, 13 Feb 2005 19:04:29 +0100, Alfredo Novoa wrote:

> One of the differences between OO languages and classic structured
> languages is that procedures are bundled with types (classes). 
> 
> Which is a bad idea BTW.

Yes it is. But does it really characterize OO or just some languages?

What about polymorphism, construction/destruction control, inheritance,
[abstract] interfaces, generic programming?

>>Just because a language is OO, doesn't mean that it forces developers to 
>>code in an OO fashion. Java is VERY OO in the fact that everything is an 
>>object except simple data types, and they have associated objects as well 
>>(ie int and Integer obejct).
> 
> You probably mean that it is not possible to create procedures that
> are not bundled with types. Which is a bad thing.

Well, it is clear that the view on the procedures as members of objects is
a bad idea. But what you have said assumes that procedures should not be
bundled with types. How that could be? After all, in any typed language a
procedure has the parameter profile as a part of its contract. Is that bad,
or just does not "bundle"?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Juha Laiho wrote:

....
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data
> to the Smalltalk object-message style of programming -- just that the
> "raw" data of the Forth program is presented as objects in Smalltalk.
> Am I just seeing ghosts here, or do these two share some conceptual
> similarity?
> 
> 

I see that Forth and Smalltalk lead to some kind of stack based thinking.
With Java one might feel forced to think in terms of return values getting
bound to symbols for semantic purpose. 

Also Forth and Smalltalk lead to a 'Keep it simple' paradigm, because
"reuseability" is always in mind. Creating and defining "vocabularies" in
Forth has a lot of similarites to the OO concept of Smalltalk.

Shin

Shin wrote:
> Juha Laiho wrote:
> 
> ...
> 
>>Finally to the sideline to Forth. I seem to see strong resemblance of
>>Forth idea of threading small pieces of code to modify a set of data
>>to the Smalltalk object-message style of programming -- just that the
>>"raw" data of the Forth program is presented as objects in Smalltalk.
>>Am I just seeing ghosts here, or do these two share some conceptual
>>similarity?
>>
>>
> 
> I see that Forth and Smalltalk lead to some kind of stack based thinking.
> With Java one might feel forced to think in terms of return values getting
> bound to symbols for semantic purpose. 
> 
> Also Forth and Smalltalk lead to a 'Keep it simple' paradigm, because
> "reuseability" is always in mind. Creating and defining "vocabularies" in
> Forth has a lot of similarites to the OO concept of Smalltalk.
> 

     In Forth, the syntax is free: a sequence of space delimited words. 
If you implement a OO extension to Forth that preserves this syntax, it 
is possible to have a conceptually different level of information 
hiding. Where in in e.g. C++ you have an explicit knowledge what is an 
object and what is a method, by force of the syntax

    <object>[.<field>].<method>([<argument>,])
in a Forth OO this would become
    [<argument> ]<object>[ <field>] <method>

That way, the information is really well hidden, to a point where you 
don't know what is an object and what is a method. (And yes, I think 
this is an advantage, and not a shortcoming). How this is useful can be 
seen in the following

Example:
     Suppose there is an object George of class Employee, and that class 
Employee has, among others, fields Name (a string) and Salary (a 
double). Suppose you access these fields by using the Forth style 
Getvalue/Setvalue, the methods ! (store) and @ (fetch), like this:

     s" George Humperdinck" George Name ! // assign string to name field
     65432. George Salary !               // assign num to salary field
     George Name display                  // display the name

Now, suppose that, for whatever reason, you need to change the structure 
of Employee, so that it contains a field Occupation of class 
Worker_type, and the Salary field is now part of Occupation. At first 
sight (and certainly in C++) you would have to change the access 
sequence to:

     65432. George Occupation Salary !
     George Occupation Salary display

However, in OO Forth we do not need to do that, as we can add a method 
to the class Employee to do the information hiding, so that the access 
sequence _remains the same_.

Employee method:{ out: double } Salary
     this Occupation Salary
;method

The new method Salary will return an object of class double (or whatever 
class Salary happens to be) on the object stack, getting it from inside 
Occupation, and the methods ! and display will act on this object, just 
like in the original sequence.
     Notice, that this is possible in Forth because we did not use . to 
delimit sub-fields of a structure, and did not use () to distinguish 
methods from data, effectively hiding _all_ information.
     To achieve this kind of transparency, in C++ you would have to 
define the Employee methods Get<field>() and Set<field>() for every 
field you might want to modify, and then you would have to change their 
implementation should the object structure change.
     In Forth, one can skip the step of defining additional get/set 
methods, and can use the native Getvalue/Setvalue methods for each field 
  class. One only needs to define additional methods if really needed, 
i.e. on object structure change.

About Forth OO extensions: there are many different implementations, as 
everybody that needs one, implements one. (This is in the venerable 
Forth tradition of re-inventing wheels ;). Some of the implementations 
(but not all) have the syntax I'm talking about; some have the
     <message>: <object>
syntax, and some have the C++ habit of doing <object>.<field> .
     The above examples are from my own Forth OO extension.
Cheers,

Responding to Laiho...

> I've been trying my hand in programming Java for a while now, but have
> failed to see the "big" difference of what is procedural and what is OO
> programming until very recently (or this is how I currently feel).

You will not understand that difference looking at OOPLs.  The OOPLs are 
3GLs (maybe 3.nGLs but n -> 0) so they all use procedural message 
passing, procedural block structuring, and stack-based scope. 
(Languages like Smalltalk do a better job of disguising it, but it is 
still there.)  That means that it is quite easy to map procedural 
paradigms onto OOPLs and a lot of very bad "OO" applications exist for 
exactly this reason.

The two most fundamental (of many) differences between OO development 
and procedural development are the elimination of hierarchical 
implementation dependencies and better management of state variables. 
Those are manifested in OO development in the way one constructs the 
software, not the syntactic widgets one uses as building blocks.

In traditional procedural development applications were built around a 
functional decomposition of the problem.  High level tasks were 
subdivided into lower level tasks forming a tree of decreasing 
abstraction and increasing number of tasks until one eventually got to 
the language's fundamental operators.  That structure and tree was not 
the problem if one just daisy-chained the leaf operations together to 
solve the problem.

The problem was that stringing together operations at the language 
operator level or close to it was enormously tedious and there tended to 
be enormous redundancy once the solution had been decomposed.  So the 
higher level nodes in the tree were used to collect and reuse the same 
sequences of leaf operations for use in different contexts.  The higher 
level node became a function that called lower level functions in a 
defined sequence.  This was enormously convenient because it allowed 
complex solutions to be expressed as sequences of various higher level 
functions in different contexts.  It also allowed convenient reuse of 
common sequences of operations via libraries, etc.

The difficulty was two-fold.  First, the lower level functions were 
extensions of their parent higher level functions.  In effect the 
specification of the higher level function included the specifications 
of all the lower level functions in descending limbs.  However, that 
only became a problem because of the second difficulty.

Since higher level functions were reused in different context the 
decomposition tree was no longer a tree; it became a lattice.  Because 
functions were reused they were called by more than one "parent".  even 
that was not a problem so long as requirements did change.

Things went downhill rapidly when requirements changed and one had to 
maintain the software.  Often a change for some high level context would 
have to be made in a relatively low level function.  That was fine so 
long as the change was relevant to /every/ higher level context that was 
a parent of the low level function.  But if the change was only needed 
for one or a few of the high level context, the other high level 
contexts would be broken because they still included the low level 
function in their specifications and they expected the old 
functionality.  Just checking all the possible contexts became a major 
task.  That sort of lattice-like dependency structure was the legendary 
Spaghetti Code.

The OO approach seeks to completely eliminate hierarchical 
implementation (specification) dependencies.  So all OO collaborations 
between objects are on a peer-to-peer basis.  For that to be possible 
one must have a flexible view of logical indivisibility (i.e., one can't 
let language operators be the "atomic" units of behavior).  The OO 
approach provides this flexibility through application partitioning, 
problem space abstraction via classes, encapsulation, and property 
definition (i.e., knowledge and behavior responsibilities).

Perhaps more important, the OOA/D approach separates message from method 
  (response).  This allows one to think of messages as announcements 
(I'm Done) of something the sender has done without worrying about who 
cares or what they will do in response.  This is in contrast to 
procedural imperatives (Do This) that arose because in the 3GLs the 
message is the procedure signature and we name procedures by what they do.

In good OOA/D designs methods are constructed so that they are 
encapsulated, self-contained, and independent of solution context (i.e., 
the sequences of operations needed to solve the overall problem).  That 
is what problem space abstraction does by defining the /intrinsic/ 
behaviors of an entity.  So one abstracts classes, defines 
relationships, identifies object responsibilities, and defines object 
responsibilities all before even thinking about connecting the dots 
sequentially to solve the overall problem.  In contrast, in procedural 
development one starts with sequences of operations and builds 
everything around them.

The other piece of the OO pie is the handling of state variables. 
Unexpected changes to global data was perceived as a major problem with 
procedural applications.  Functional programming solved this problem by 
eliminating state variables completely (all relevant state information 
is passed to and returned by the function).  In OO development a 
different tack was chosen.  State variables were encapsulated as object 
attributes and class diagrams are normalized to ensure a single "owner" 
of the state data.  The primary OO techniques to manage access to state 
variables are relationship instantiation and navigation.

If one looks at a typical OO Class Diagram, every class is usually 
reachable from every other class via some path of relationships. 
However, that only defines the high level structure.  An individual 
object of one class is usually connected to only a smallish subset 
(often exactly one) of all the objects of the class to which it is 
related.  In OOA/D relationships (other than subclassing) are binary so 
any navigation across multiple relationships in a path results in 
successive pruning of the reachable objects for each relationship.  This 
severely limits what objects one can actually reach (and, consequently, 
what attributes can be modified) from a particular object in hand.  [The 
OO paradigm provides other mechanisms for limiting write access, but 
this is the most fundamental and ubiquitous technique.]

The in OO relationship instantiation is regarded as a fundamental aspect 
of design.  In fact, relationships are regarded as an important vehicle 
for enforcing problem space rules and policies that must be captured in 
the problem.  In addition, the rules and policies about who specifically 
participates in a particular relationship are usually separated and 
encapsulated elsewhere that in the participating objects.  So objects 
send messages to one another during collaborations that are addressed by 
relationship navigation without needing to worry about whether the 
"right" object is being accessed.  (A bonus is that since relationships 
are static in nature, using properly them to enforce business rules 
usually leads to reduced executable code size.)

Both of these things profoundly change the way one designs software in 
OOA/D vs. Structured A&D.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Hi Juha,

have you tried working with design patterns? These combine procedural 
and OO techniques in a powerful way, providing e.g. state machine 
architectures, synchronisation for multitaskers, memory pooling etc.

These very useful techniques are available in almost identical form for 
Java, C++ and Smalltalk. I have also used a few in Forth.

Some patterns do not require OO, they work fine without. So OO can be a 
good thing, but there are other techniques giving you comparable power. 
Polymorphism can easily be done in non-OO systems using function tables.

Best regards,
     Daniel

One thing that made me "get it" was to think of the difference between
procedural and OO as the difference between behavior (procedures) and
responsbility.

Of course, all OO programming is really procedural programming under
the hood.  All that makes OO languages do what they do is that the
language hides the details of the pointers that determine which block
of data a given method will act upon.  But what makes OO so useful is
that that language hides away those details and allows the programmer
to think in abstractions that would be obscured if the programmer had
to do all of that himself. The difference is abstract, but it is no
less real than the abstraction that lets us treat the position of
microscopic switches as 0's and 1's.

In procedural programming, the fundamental break is between data and
behavior.  There are different kinds of data, but at the level of how
to write code, business data such as customer names is treated the same
as transient data used to manage program flow.  There is behavior, and
that upon which behavior acts.

In OO, the programmer can think in terms of responsibility.  There are
different kinds of objects, those that primarily manage business data,
those that manage program flow, those that manage behavior, etc.  But
the key difference from procedural programming is that the programmer
can think of objects as a single unit that has a given responsibility.
The data it uses and the behavior performed on that data are
encapsulated in a single unit that has responisbility for both its own
behavior and the data that behavior acts on.

At the level of overall program design, all we have to think about is
how objects will interact with each other.  We still have to think
about the procedural aspects when designing individual objects, but we
have the additional abstraction of the object as an atomic unit to use
at the higher abstraction level of overall program design.  Because of
this, we are able to create a nested conceptual heirarchy rather than a
linear (sequential) heirarchy.

Polymorphism is an essential aspect of this higher level of
abstraction, but not quite in the way you describe.  Thinking of
polymorphism in terms of an if..then construct is technically accurate,
but it does not capture the level of abstraction that is acheived when
you think of it in terms of substitutable responsibility (aka Liskov
Substitution Principle).  Similarly, long message chains are not a
feature of OO so much as an artifact of it.  When thinking in terms of
a heirarchy of responsibilities, long message chains are just the
navigation of this nested structure to get to the object that is
responsible for the content of the message.  This includes in many
cases objects whose sole responsibility is dispatching those messages.

The difference is to some extent one of degree.  Some programmers can
use purely procedural languages in ways that come very close to
creating OO-like abstractions; some OO programmers, particularly those
just learning it, use OO languages to implment what is basically a
sophisticated procedural solution.  This is a "better C" in C++ terms,
or as I call it, the "bags of data" approach.  It is also sometimes
referred to as Object-Based programming.  The real leap comes when the
programmer grasps the higher abstraction that is the essence of OO.
While it is possible to implement this abstraction in any language, OO
languages make it much simpler and more natural.

--Kyle Bennett
Tucson, AZ

Bruce Eckel's book "Thinking In Java" is available online as a free
download.
IT may help you along in your quest for OO-nderstanding

H. S. Lahman wrote:
> Since higher level functions were reused in different context the
> decomposition tree was no longer a tree; it became a lattice.
When classes are resued in different context, you will also create a
lattice. There are no difference between a function and method call in
this aspect.

> Things went downhill rapidly when requirements changed and one had to

> maintain the software.  Often a change for some high level context
would
> have to be made in a relatively low level function.

The same problem exists with "low-level" class libraries. You can't
change the behaivor of a class, unless it should be changed in all
contexts. Otherwise you have to write a new class or method.

> So all OO collaborations
> between objects are on a peer-to-peer basis.
I think that collaborations between functions can be defined as "on
peer-to-peer basis" too.

> Perhaps more important, the OOA/D approach separates message from
method
> (response).
How is messages separated from methods in C++ or Java?

> In good OOA/D designs methods are constructed so that they are
> encapsulated, self-contained, and independent of solution context
In good functional designs, methods are constructed so that they are
encapsulated, self-contained and independent of solution context.

> In contrast, in procedural
> development one starts with sequences of operations and builds
> everything around them.
Because most OOPLs are procedural, this is true for them too.

Fredrik Bertilsson
http://butler.sourceforge.net

"Daniel Ciesinger" <ciesinger@gmx.net> wrote in message 
news:420fdaa1_1@news.arcor-ip.de...
> Hi Juha,
>
> have you tried working with design patterns? These combine procedural and 
> OO techniques in a powerful way, providing e.g. state machine 
> architectures, synchronisation for multitaskers, memory pooling etc.

Thought I'd add a few words.

Java vs Smalltalk:
I also see the tendency in Java of having long methods and a less Object 
Oriented style.  The flip side of this is that Smalltalk programs can turn 
into "programming by responsibility fragmentation" - whenever you try to 
find where something is actually happening, you plunge down a long row of 
message calls, all (rather) trivial.  You find that all distinctions that 
appear as IF or CASE elsewhere, are lost - because the distinctions are made 
by virtue of calling the method on an instance of *this* class rather than 
some other class. Everything happens elsewhere.

So in a big Java program you can find the method that does something and 
read through the whole page - but you may not be able to subclass it, change 
it, generalise it or otherwise refactor it. (If you could, you would 
generalize it until you had "programming by responsibility fragmentation" 
again)

Smalltalkers are used to being able to refactor, turning all methods into 
almost trivial one-liners. You can abstract out everything, make your own 
control structures, iterators etc.
This is also a feature of Forth - Forthers keep generalizing and refactoring 
until they've got the basic atoms of their structure right. (And then, the 
methods or constructs are given an unreadable name like ps^^ or something, 
turning your lines to line noise, and you need to remember that ps^^ takes 
four things off the stack and leaves three others)



As for patterns: I love this comment from comp.object. 1999/09/21

"Frank A. Adrian" <fadrian@uswest.net> writes:

Thi is where I chime in with my usual comment:



 a design pattern is not a feature, it's a bug.



If you're writing small variations of the same code over and over again,

something is wrong.  If the language doesn't allow you to factor the

common parts, it's not good enough.  The corollary to that is that no

programming language is currently good enough, probably not even close.

The corollary to *that* is that programming languages should allow us to

build programming languages that have a chance at being good enough,

at least for our specific problem domain.

(unquote)



Some things that are patterns in one language are either not needed or are 
simple infrastructure in others (like iterators in Smalltalk vs Java).

There are other languages that are even stronger than Smalltalk, where well 
known Smalltalk patterns can be implemented trivially and become simple 
infrastructure.



--Arne

>
> These very useful techniques are available in almost identical form for 
> Java, C++ and Smalltalk. I have also used a few in Forth.
>
> Some patterns do not require OO, they work fine without. So OO can be a 
> good thing, but there are other techniques giving you comparable power. 
> Polymorphism can easily be done in non-OO systems using function tables.
>
> Best regards,
>     Daniel
> 

Arne Dehli Halvorsen schrieb:
> "Daniel Ciesinger" <ciesinger@gmx.net> wrote in message 
> news:420fdaa1_1@news.arcor-ip.de...

>  a design pattern is not a feature, it's a bug.
> 
> If you're writing small variations of the same code over and over again,
> something is wrong.

That depends a bit on where and what you program. Generalisation often 
means larger and less efficient code (you need to somehow parameterize 
it) which is OK in a PC but barely acceptable in an embedded controller.

So for embedded control, I'll keep my Forth and C (non-OO) statemachine 
  patterns. From time to time, I will use factory or bridge patterns in 
Java and C++. Whatever suits my application...

Best regards,
    Daniel

"Arne Dehli Halvorsen" <arne.d.h@online.no> writes:
> As for patterns: I love this comment from comp.object. 1999/09/21
> 
> "Frank A. Adrian" <fadrian@uswest.net> writes:
> 
> This is where I chime in with my usual comment: a design pattern is
> not a feature, it's a bug.  If you're writing small variations of
> the same code over and over again, something is wrong.  If the
> language doesn't allow you to factor the common parts, it's not good
> enough.  The corollary to that is that no programming language is
> currently good enough, probably not even close.  The corollary to
> *that* is that programming languages should allow us to build
> programming languages that have a chance at being good enough, at
> least for our specific problem domain.
> 
> (unquote)

     Great quote.  Design patterns are an indication of where a
language lacks sufficient power.  I disagree with his statement that
"no programming language is currently good enough", though.  I've been
using Lisp lately and Lisp macros very elegantly provide exactly the
functionality he describes.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.    | The experts in large scale distributed OO
                         | systems design and implementation.
          pjm@spe.com    | (C++, Java, ObjectStore, Oracle, CORBA, UML)

On Sun, 13 Feb 2005 19:59:22 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>> One of the differences between OO languages and classic structured
>> languages is that procedures are bundled with types (classes). 
>> 
>> Which is a bad idea BTW.
>
>Yes it is. But does it really characterize OO or just some languages?

Good question.

The problem is that there is not an agreeable definition of what OO
is, but all the OO languages I know have that flaw.

>What about polymorphism

Polymorphism is not exclusive of OO.

>, construction/destruction control

This is also a lot older than OO.

>, inheritance,

This is one of the key components of OO IMO.

But inheritance is a rather fuzzy word. It would be more precise  to
talk about "delegation" IMO. For instance when you create abstract
classes or interfaces you are delegating some implementation aspects
to the users of the types (classes and interfaces are types).

>[abstract] interfaces, generic programming?

Very related to "delegation".

>Well, it is clear that the view on the procedures as members of objects is
>a bad idea.

Well, I said types. Procedures as members of values or variables don't
make sense.

The worst thing about OO is the sloppy terminology. If everything is
an object then object means anything, and it is hard to communicate
with an one word vocabulary.

> But what you have said assumes that procedures should not be
>bundled with types.

By bundling procedures with types I mean something like this:

type Integer
{
  ...

  operator Double Mul(Double d)
  {
    ...
  }
}

type Double
{
  ...

  operator Double Mul(Integer i)
  {
    ...
  }
}

> How that could be?

commutative operator Double *(Double d, Integer i)
{
  ...
}

> After all, in any typed language a
>procedure has the parameter profile as a part of its contract. Is that bad,
>or just does not "bundle"?

It does not bundle. An operator might be member of several types. To
force the assotiation of each operator (procedure) with an unique
type is a constraint that does not match the real world.


Regards

On Mon, 14 Feb 2005 10:06:06 +0000, Patrick May wrote:

> Great quote.  Design patterns are an indication of where a language
> lacks sufficient power.  I disagree with his statement that "no
> programming language is currently good enough", though.  I've been using
> Lisp lately and Lisp macros very elegantly provide exactly the
> functionality he describes.

Um, excuse me. My understanding of design patterns is that they're
basically "best practices" Not a metric of a language.

http://www.cmcrossroads.com/bradapp/docs/patterns-nutshell.html

On Mon, 14 Feb 2005 15:57:12 +0100, Alfredo Novoa wrote:

> On Sun, 13 Feb 2005 19:59:22 +0100, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>> One of the differences between OO languages and classic structured
>>> languages is that procedures are bundled with types (classes). 
>>> 
>>> Which is a bad idea BTW.
>>
>>Yes it is. But does it really characterize OO or just some languages?
> 
> Good question.
> 
> The problem is that there is not an agreeable definition of what OO
> is, but all the OO languages I know have that flaw.
> 
>>What about polymorphism
> 
> Polymorphism is not exclusive of OO.

OK, let's talk about true = dynamic polymorphism.

>>, construction/destruction control
> 
> This is also a lot older than OO.

Maybe, I'm not sure.

>>, inheritance,
> 
> This is one of the key components of OO IMO.

But Ada 83, which was object-based, already had inheritance (very limited
though). Also it is not so obvious.

> But inheritance is a rather fuzzy word. It would be more precise  to
> talk about "delegation" IMO. For instance when you create abstract
> classes or interfaces you are delegating some implementation aspects
> to the users of the types (classes and interfaces are types).

Yes, but it is not quite. Inheritance may also provides some ready-to-use
implementations. It may also control which implementations to take (things
like final methods etc)

>>[abstract] interfaces, generic programming?
> 
> Very related to "delegation".

Related but different. Generic programming is an ability to write programs
in terms of sets of types. From this point of view it is obviously related
to polymorphism.

>>Well, it is clear that the view on the procedures as members of objects is
>>a bad idea.
> 
> Well, I said types. Procedures as members of values or variables don't
> make sense.

Sure.

However disguising member values as procedures and vice versa makes a lot
of sense. One just should not mix syntactic sugar with reality.

> The worst thing about OO is the sloppy terminology. If everything is
> an object then object means anything, and it is hard to communicate
> with an one word vocabulary.

Yes.

>> But what you have said assumes that procedures should not be
>>bundled with types.
> 
> By bundling procedures with types I mean something like this:
> 
> type Integer
> {
>   ...
> 
>   operator Double Mul(Double d)
>   {
>     ...
>   }
> }
> 
> type Double
> {
>   ...
> 
>   operator Double Mul(Integer i)
>   {
>     ...
>   }
> }
> 
>> How that could be?
> 
> commutative operator Double *(Double d, Integer i)
> {
>   ...
> }
> 
>>After all, in any typed language a
>>procedure has the parameter profile as a part of its contract. Is that bad,
>>or just does not "bundle"?
> 
> It does not bundle. An operator might be member of several types. To
> force the assotiation of each operator (procedure) with an unique
> type is a constraint that does not match the real world.

OK, it means that you are just against some definite way of specifying
visibility rules. In Ada 95 visibility is not controlled on the type level.
It is completely decoupled from types. Visibility is maintained by
packages. A package may have more than one or node types declared. Yet Ada
95 is considered an OO languages. So the bundling you are talking about
cannot be attributed to OO. It is a language design fault.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

BR <brodriguez@comcast.net> writes:
> On Mon, 14 Feb 2005 10:06:06 +0000, Patrick May wrote:
> > Great quote.  Design patterns are an indication of where a
> > language lacks sufficient power.  I disagree with his statement
> > that "no programming language is currently good enough", though.
> > I've been using Lisp lately and Lisp macros very elegantly provide
> > exactly the functionality he describes.
> 
> Um, excuse me. My understanding of design patterns is that they're
> basically "best practices" Not a metric of a language.

     The patterns in the Gang of Four's "Design Patterns" are, for the
most part, ways of addressing the lack of expressive power in
languages such as C++ and Java.

> http://www.cmcrossroads.com/bradapp/docs/patterns-nutshell.html

     I'll see your Brad Appleton and raise you a Peter Norvig:

          http://www.norvig.com/design-patterns/

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.    | The experts in large scale distributed OO
                         | systems design and implementation.
          pjm@spe.com    | (C++, Java, ObjectStore, Oracle, CORBA, UML)

"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
news:gve111tcsfkbf361ipa399g7miar9l6vcn@4ax.com...
> On Sun, 13 Feb 2005 19:59:22 +0100, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
>
> >> One of the differences between OO languages and classic structured
> >> languages is that procedures are bundled with types (classes).
> >>
> >> Which is a bad idea BTW.
> >
> >Yes it is. But does it really characterize OO or just some languages?
>
> Good question.
>
> The problem is that there is not an agreeable definition of what OO
> is, but all the OO languages I know have that flaw.

In Common Lisp, methods do not belong to classes, but to "generic
functions". One can define a generic function, then add methods to it.
Methods can specialize on an arbitrary number of parameters, and can be
combined (to add methods that will always get called before, after or
around other methods).

  (defgeneric foo (a b c))

  (defmethod foo ((a string) b c)
    (print "method 1"))

  (defmethod foo ((a string) (b integer) (c symbol))
    (print "method 2"))

  (foo "bar" "baz" "qux")
  => method 1

  (foo "bar" 10 'hello)
  => method 2

  (defmethod foo :before ((a string) b c)
    (print "before"))

  (defmethod foo :after ((a string) (b integer) (c symbol))
    (print "after"))

  (foo "bar" "baz" "qux")
  => before
     method 1

  (foo "bar" 10 'hello)
  => before
     method 2
     after


--
Matthieu Villeneuve

Daniel Ciesinger <ciesinger@gmx.net> wrote:

>Arne Dehli Halvorsen schrieb:
>> "Daniel Ciesinger" <ciesinger@gmx.net> wrote in message 
>> news:420fdaa1_1@news.arcor-ip.de...
>
>>  a design pattern is not a feature, it's a bug.
>> 
>> If you're writing small variations of the same code over and over again,
>> something is wrong.
>
>That depends a bit on where and what you program. Generalisation often 
>means larger and less efficient code (you need to somehow parameterize 
>it) which is OK in a PC but barely acceptable in an embedded controller.
>
>So for embedded control, I'll keep my Forth and C (non-OO) statemachine 
>  patterns. From time to time, I will use factory or bridge patterns in 
>Java and C++. Whatever suits my application...
>
>Best regards,
>    Daniel

I disagree.  With languages like C++, you can easily inline function calls
in such a way that they are just as fast as the non-generalized code.  On
the flipside, if you have excessive code duplication, generalization can
reduce overall size, and because the size is smaller, there is less data to
cache and generally that also results in efficiency benefits.  Some modern
languages are somewhat smart and will auto-inline the hotspots where needed
so you don't have to do as much of this fine tuning.

So to sum up: highly generalized code will always be more efficient and have
a smaller footprint than the ungeneralized code.  Generalized code is a big
win all the way around -- efficiency, reduced complexity, understandability,
flexibility ...  Just do it!  :)

Ian

---
http://www.upright.net/ian/

On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:

>> This is where I chime in with my usual comment: a design pattern is
>> not a feature, it's a bug.  If you're writing small variations of
>> the same code over and over again, something is wrong.  If the
>> language doesn't allow you to factor the common parts, it's not good
>> enough.  The corollary to that is that no programming language is
>> currently good enough, probably not even close.  The corollary to
>> *that* is that programming languages should allow us to build
>> programming languages that have a chance at being good enough, at
>> least for our specific problem domain.
>> 
>> (unquote)
>
>     Great quote.  Design patterns are an indication of where a
>language lacks sufficient power.

I agree. Design patterns are workarounds for language flaws.


Regards

On Mon, 14 Feb 2005 16:49:54 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>> Polymorphism is not exclusive of OO.
>
>OK, let's talk about true = dynamic polymorphism.

IMO it is very related to pointer based delegation and jump table
hidding.

>>>, construction/destruction control
>> 
>> This is also a lot older than OO.
>
>Maybe, I'm not sure.

See Lisp and the OO languages without garbage collection.

>>>, inheritance,
>> 
>> This is one of the key components of OO IMO.
>
>But Ada 83, which was object-based, already had inheritance (very limited
>though). Also it is not so obvious.

Perhaps it is considered "object-based" because it had limited
inheritance.

>Yes, but it is not quite. Inheritance may also provides some ready-to-use
>implementations.

But they are "delegable".

> It may also control which implementations to take (things
>like final methods etc)

This is delegation control. For instance a final clause means that
further delegation is not allowed.

>>>[abstract] interfaces, generic programming?
>> 
>> Very related to "delegation".
>
>Related but different. Generic programming is an ability to write programs
>in terms of sets of types. From this point of view it is obviously related
>to polymorphism.

The "generity" of the procedures is achieved thanks to delegation.

For instance we can develop generic sorting procedures delegating some
operations like value comparation.

Interfaces are a very good example of this.

>However disguising member values as procedures and vice versa makes a lot
>of sense. One just should not mix syntactic sugar with reality.

I don't understand this.

What is to disguis member values as procedures?

>OK, it means that you are just against some definite way of specifying
>visibility rules.

Indeed it is a way to specify visibility rules which has bad side
effects. 

> In Ada 95 visibility is not controlled on the type level.
>It is completely decoupled from types. Visibility is maintained by
>packages. A package may have more than one or node types declared.

That's fine.

> Yet Ada
>95 is considered an OO languages. So the bundling you are talking about
>cannot be attributed to OO. It is a language design fault.

Ok, I agree.


Regards

"Arne Dehli Halvorsen" <arne.d.h@online.no> wrote in message news:jRZPd.8611$Sl3.264517@news4.e.nsc.no...
> As for patterns: I love this comment from comp.object. 1999/09/21
>
> "Frank A. Adrian" <fadrian@uswest.net> writes:
> Thi is where I chime in with my usual comment:
>
>  a design pattern is not a feature, it's a bug.
>
> If you're writing small variations of the same code over and over again,
> something is wrong.  If the language doesn't allow you to factor the
> common parts, it's not good enough.  The corollary to that is that no
> programming language is currently good enough, probably not even close.
> The corollary to *that* is that programming languages should allow us to
> build programming languages that have a chance at being good enough,
> at least for our specific problem domain.

Here's a good article about the steps you can follow to move from recognizing similarities to having both a tailor-made
language and a development environment for that problem domain:
http://st-www.cs.uiuc.edu/users/droberts/evolve.html
The first response to writing small variations of the same code is to use language features like loops and functions.
Next up is patterns, then frameworks, then domain-specific languages, then full IDEs for such languages.

All the evidence I've seen (and since it's my job, I see a fair bit, but may be biased) points to the fact that such
domain-specific languages offer far greater increases in productivity than those observed between common programming
languages: more like the jump from Assembler to 3GLs. An interesting class of such languages is Domain-Specific Modeling
languages: visual languages, which have been found by practitioners (e.g. David Weiss at Lucent) to be better than
textual DSLs. For instance, DSMs generally show an increase in productivity of 500%-1000%, whereas Java only outstrips
BASIC by 20%. Perhaps the main reason is that from DSM languages you generate full code, normally in a 3GL, with a
domain-specific code generator. Since an expert developer in that domain creates the DSM language and generator, the
result is better than most developers wrote by hand, and there is no need to edit the generated code. Generated code is
just a by-product on the way to the executable: if you want changes, change the model or change the generator.

Of course, this is only most effective for a company that continues to work in the same domain: if the company just does
project work for other companies, the domain may change each time so there's little chance to notice or benefit from the
repeated similarities between different bits of code. And if there's only one developer working on a 2-month project,
there might not be much point in optimising the production of code. But for projects of five developers and upwards,
making three or more variants of the same product (a product family or product line), it can really hit the spot.

[Full disclosure: My company provides metaCASE tools, which make the process of creating such domain-specific modeling
languages and tool support for them much easier - the lex and yacc of DSM language creation, and an answer to the second
corollary above. Microsoft's Software Factories and the prototype support in Visual Studio Team System are aiming in a
similar direction. If you're interested in finding out more, check out the vendor-independent DSM Forum -
www.dsmforum.org].

Back to the OO side: OO helps you to do things you'd want to do in any language, i.e. raise the level of abstraction,
reduce the amount of code and reduce the amount of complexity. I'll take any technique that will help me do that,
actively seek out new techniques, try to understand when and how best to use them, and then strive to use them where
they're better than older, more primitive solutions. Having a higher level of abstraction doesn't MAKE you better:
writing spaghetti or ten levels of if statements is equally possible in Assembler, procedural languages, Smalltalk or
DSM. But higher-level techniques, like creating new language concepts when needed, are possible in DSM and progressively
harder as you go back down the scale.

Steve
~~~~~~~~~~~~~ http://www.metacase.com ~~~~~~~~~~~~
Steven Kelly, Product Development Manager, MetaCase

"Juha Laiho" <Juha.Laiho@iki.fi> wrote in message 
news:culmrd$d7e$1@ichaos.ichaos-int...
/snip/
> So, summarizing; what I feel is non-OO in the way I see Java code written:
> - many methods written to return no value (void)

This is quite normal for event driven programming,
because the driver doesn't care what the listener
will do with the event.

> - if/else constructs used instead of object polymorphism to achieve
>  differences in program behaviour

Unfortunately, most of the beginner tutorials have
awkward procedural examples of using listeners and
such, which devolve into if-else testing using
"instanceof". However, re-writing such tutorials
to use polymorphism would confuse beginners too much.

I am a firm supporter of polymorphism and multiple
inheritance. I also use "instanceof" only in limited
down-casting circumstances where I do not author the
class/interface definitions. In those cases where I author
the definitions, I can always avoid "instanceof" and use
implicit down-casting provided by the JVM as appropriate;
I never need to use explicit down-casting or generics in
JDK 1.5, although generics are convenient.

> - a lot of avoidable local variables used (references to which could then
>  be accidentally leaked somewhere, and thus be ineligible for garbage
>  collection)

Local variables disappear when the method returns. If the
method is long running, then I explicitly nullify the locals.
I also use block-scoped variables to reduce the visibility,
and I still nullify them. (When a block-scoped variable goes
out of scope, its value is not necessarily nullified.)

I use local variables to help with debugging, so that I can
single-step through the method and see the exact values
returned/calculated. I rarely use a method call within another
method's parameter list, nor will I use chaining (like the
chaining provided by StringBuffer). I doubt there are any
significant performance issues with my style, and it is
much more readable and maintainable.


> This still leaves me to think about the need of exceptions in OO code:
> I think exceptions have their place, but are often misused in Java.

Exceptions should be truly exceptional. However, the "finally{}" block
is quite useful by itself without catching an exception.

> My experience with Smalltalk doesn't yet cover exception use, so cannot
> make any comparisions on this (does Smalltalk even have exceptions?).
>
> ... and a further question: is "message-passing OO" as used in Smalltalk
> the only form of object-oriented programming, or are there other variants
> of "pure OO" (as in "not tainted by procedural programming")?

All OO programming eventually devolves into procedural programming.
At some point, an algorithm or calculation must be performed, which
is procedural, by definition. OOP merely aids the programmer in
expressing the semantics needed to arrive at the proper procedural
processing.

/snip/

On Mon, 14 Feb 2005 18:47:39 +0100, Alfredo Novoa wrote:

> On Mon, 14 Feb 2005 16:49:54 +0100, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> wrote:
> 
>>> Polymorphism is not exclusive of OO.
>>
>>OK, let's talk about true = dynamic polymorphism.
> 
> IMO it is very related to pointer based delegation and jump table
> hidding.

Yes, though pointer semantics is not a requirement. Dynamic polymorphism
can be also by-value. Though if you meant vtable pointer, then there could
be a more general approach based on type tags rather than pointers.

>>Yes, but it is not quite. Inheritance may also provides some ready-to-use
>>implementations.
> 
> But they are "delegable".
> 
>> It may also control which implementations to take (things
>>like final methods etc)
> 
> This is delegation control. For instance a final clause means that
> further delegation is not allowed.

OK.

>>>>[abstract] interfaces, generic programming?
>>> 
>>> Very related to "delegation".
>>
>>Related but different. Generic programming is an ability to write programs
>>in terms of sets of types. From this point of view it is obviously related
>>to polymorphism.
> 
> The "generity" of the procedures is achieved thanks to delegation.
> 
> For instance we can develop generic sorting procedures delegating some
> operations like value comparation.

Yes, but generic procedure knows nothing about delegation. It only knows
that there is "=" and "<". It does not care what implements them. Something
that calls polymorphic procedures need not be polymorphic itself.

>>However disguising member values as procedures and vice versa makes a lot
>>of sense. One just should not mix syntactic sugar with reality.
> 
> I don't understand this.
> 
> What is to disguis member values as procedures?

In Pascal and Ada there is no any syntactical difference between call to a
parameterless function, literal, taking the value of a variable.

In this spirit, with prefix notation, a member can be implemented by a
function and vice versa. Ideally all members should be just interfaces to
be implemented either by "real" members or by getter[/setter] at
programmer's choice.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Arne Dehli Halvorsen" <arne.d.h@online.no> wrote in message 
news:jRZPd.8611$Sl3.264517@news4.e.nsc.no...
>
> ...
> This is also a feature of Forth - Forthers keep generalizing and 
> refactoring until they've got the basic atoms of their structure right. 
> (And then, the methods or constructs are given an unreadable name like 
> ps^^ or something, turning your lines to line noise, and you need to 
> remember that ps^^ takes four things off the stack and leaves three 
> others)

Gosh, I don't know what Forth you're familiar with, but thank goodness no 
Forth code I've ever seen had names like ps^^.  Most code from competant 
programmers has pretty clear names, although naming is something of an art 
in any language.  And it should be easy to tell what its stack behavior is, 
because the almost universal custom in Forth progamming is to indicate that 
with a comment associated with every definition.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
================================================== 

Responding to Frebe...

>>Since higher level functions were reused in different context the
>>decomposition tree was no longer a tree; it became a lattice.
> 
> When classes are resued in different context, you will also create a
> lattice. There are no difference between a function and method call in
> this aspect.

Object reuse does not matter.  Any collaborations are always 
peer-to-peer in any context.  There is no hierarchical implementation 
dependency, regardless of reuse context.  No class' specification 
depends on any other class' specification in a hierarchical fashion 
unless the class is embedded in its implementation.  Corollary: classes 
embedded in another class' implementation are not directly accessible 
for collaboration.

>>Things went downhill rapidly when requirements changed and one had to 
>>maintain the software.  Often a change for some high level context would 
>>have to be made in a relatively low level function.
> 
> 
> The same problem exists with "low-level" class libraries. You can't
> change the behaivor of a class, unless it should be changed in all
> contexts. Otherwise you have to write a new class or method.

There aren't any "low-level" class libraries.  It doesn't matter where 
the class comes from, all collaborations are peer-to-peer and there are 
no hierarchical specification dependencies among classes.

>>So all OO collaborations
>>between objects are on a peer-to-peer basis.
> 
> I think that collaborations between functions can be defined as "on
> peer-to-peer basis" too.

Not if the function's specification includes the specification of 
functions that it invokes hierarchically.

>>Perhaps more important, the OOA/D approach separates message from method 
>>(response).
> 
> How is messages separated from methods in C++ or Java?

I said "OOA/D".  The OOPLs are inherently procedural because they are 
3GLs and there is no separation of message and method during OOP.  That 
is not a problem so long as the OOA/D was done with the proper mindset.

>>In good OOA/D designs methods are constructed so that they are
>>encapsulated, self-contained, and independent of solution context
> 
> In good functional designs, methods are constructed so that they are
> encapsulated, self-contained and independent of solution context.

Not if the function's specification includes the specification of 
functions that it invokes hierarchically.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:

>"Arne Dehli Halvorsen" <arne.d.h@online.no> writes:
>> As for patterns: I love this comment from comp.object. 1999/09/21
>> 
>> "Frank A. Adrian" <fadrian@uswest.net> writes:
>> 
>> This is where I chime in with my usual comment: a design pattern is
>> not a feature, it's a bug.  If you're writing small variations of
>> the same code over and over again, something is wrong.  If the
>> language doesn't allow you to factor the common parts, it's not good
>> enough.  The corollary to that is that no programming language is
>> currently good enough, probably not even close.  The corollary to
>> *that* is that programming languages should allow us to build
>> programming languages that have a chance at being good enough, at
>> least for our specific problem domain.
>> 
>> (unquote)
>
>     Great quote.  Design patterns are an indication of where a
>language lacks sufficient power. 


Hmmm.  There could be something to this.  We need Visitor because we
don't have multiple dispatch.  We need Command because we don't have
closures.  Etc, etc.  

On the other hand, I refuse to believe that the perfect language ought
to be defined as one in which there are no repeating structures.  I
think every language will always be composable into patterns of use.


-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716   


"The aim of science is not to open the door to infinite wisdom, 
 but to set a limit to infinite error."
    -- Bertolt Brecht, Life of Galileo

> >     Great quote.  Design patterns are an indication of where a
> >language lacks sufficient power.

Peter Norvig's examples
http://www.norvig.com/design-patterns/ppframe.htm


> Hmmm.  There could be something to this.  We need Visitor because we
> don't have multiple dispatch.  We need Command because we don't have
> closures.  Etc, etc.

A Nice example
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/VisitorPatternMultiMethodExample


> On the other hand, I refuse to believe that the perfect language
ought
> to be defined as one in which there are no repeating structures.  I
> think every language will always be composable into patterns of use.

"A Functional Pattern System for Object-Oriented Design" (pdf)
http://www.mm.informatik.tu-darmstadt.de/staff/kuehne/fps/

Robert C. Martin <unclebob@objectmentor.com> writes:

> On the other hand, I refuse to believe that the perfect language ought
> to be defined as one in which there are no repeating structures.

I agree.  Just because some design patterns may turn out to be very
tiny or unnecessary with additional language features does not mean
the concept is bad.  Everybody uses design patterns, such as when
teaching novices how to program well, they just may not use those
particular terms.  I'm wary of over-formalizing them though, which
I've seen done.

-- 
Darin Johnson
    "Particle Man, Particle Man, doing the things a particle can"

Robert C. Martin wrote:
> On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:
> 
> 
<snip>
>>
>>    Great quote.  Design patterns are an indication of where a
>>language lacks sufficient power. 
> 
> 
> 
> Hmmm.  There could be something to this.  We need Visitor because we
> don't have multiple dispatch.  We need Command because we don't have
> closures.  Etc, etc. 

I would think it wouldn't be too difficult to go through the populat patterns 
and indicate which are really "patterns" and which are work-arounds for 
language deficiencies.

H. S. Lahman wrote:
> There aren't any "low-level" class libraries.  It doesn't matter
where
> the class comes from, all collaborations are peer-to-peer and there
are
> no hierarchical specification dependencies among classes.

If there are no "low-level" class libraries, there are no "low-level"
functions. Please explain why it is no hierachical dependencies in
methods specifications, like in function specifications. The only
difference between a function and a method is that the function is
bundled together with a class and can access an object state.

> > I think that collaborations between functions can be defined as "on
> > peer-to-peer basis" too.
> Not if the function's specification includes the specification of
> functions that it invokes hierarchically.

But this is the same for method specifications.

> > How is messages separated from methods in C++ or Java?
> I said "OOA/D".  The OOPLs are inherently procedural because they are

> 3GLs and there is no separation of message and method during OOP.

This thread started with a discussion about OO programming, not about
A/D. If the focus on programming and not A/D, doesn't method
specifications have hierachical dependencies in the same way as
functions?

Fredrik Bertilsson
http://butler.sourceforge.net

On Mon, 14 Feb 2005 16:55:33 -0600, Robert C. Martin wrote:

> On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:
> 
>>"Arne Dehli Halvorsen" <arne.d.h@online.no> writes:
>>> As for patterns: I love this comment from comp.object. 1999/09/21
>>> 
>>> "Frank A. Adrian" <fadrian@uswest.net> writes:
>>> 
>>> This is where I chime in with my usual comment: a design pattern is
>>> not a feature, it's a bug.  If you're writing small variations of
>>> the same code over and over again, something is wrong.  If the
>>> language doesn't allow you to factor the common parts, it's not good
>>> enough.  The corollary to that is that no programming language is
>>> currently good enough, probably not even close.  The corollary to
>>> *that* is that programming languages should allow us to build
>>> programming languages that have a chance at being good enough, at
>>> least for our specific problem domain.
>>> 
>>> (unquote)
>>
>>     Great quote.  Design patterns are an indication of where a
>>language lacks sufficient power. 
> 
> Hmmm.  There could be something to this.  We need Visitor because we
> don't have multiple dispatch.  We need Command because we don't have
> closures.  Etc, etc.  
> 
> On the other hand, I refuse to believe that the perfect language ought
> to be defined as one in which there are no repeating structures.  I
> think every language will always be composable into patterns of use.

Once old patterns became features of the programming languages new ones
would appear at a higher abstraction level of new features...

There will be an ever-growing hierarchy of languages of increasing power
with some patterns on top of it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Mon, 14 Feb 2005 16:55:33 -0600, Robert C. Martin wrote:
> > On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:
> > >     Great quote.  Design patterns are an indication of where a
> > >language lacks sufficient power.
> > 
> > Hmmm.  There could be something to this.  We need Visitor because
> > we don't have multiple dispatch.  We need Command because we don't
> > have closures.  Etc, etc.
> > 
> > On the other hand, I refuse to believe that the perfect language
> > ought to be defined as one in which there are no repeating
> > structures.  I think every language will always be composable into
> > patterns of use.
> 
> Once old patterns became features of the programming languages new
> ones would appear at a higher abstraction level of new features...
> 
> There will be an ever-growing hierarchy of languages of increasing
> power with some patterns on top of it.

     I tend to agree with both of you at the moment, but I'm playing
around with macro generating macros in Common Lisp so my opinion may
change.  Perhaps it is possible to design a language that manages
abstraction directly.  Perhaps Common Lisp is that language.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.    | The experts in large scale distributed OO
                         | systems design and implementation.
          pjm@spe.com    | (C++, Java, ObjectStore, Oracle, CORBA, UML)

"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message
news:h0p1119c7vnnte3ulucp0cg6fboa53sfsv@4ax.com...
> On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:
>
> >> This is where I chime in with my usual comment: a design pattern is
> >> not a feature, it's a bug.  If you're writing small variations of
> >> the same code over and over again, something is wrong.  If the
> >> language doesn't allow you to factor the common parts, it's not good
> >> enough.  The corollary to that is that no programming language is
> >> currently good enough, probably not even close.  The corollary to
> >> *that* is that programming languages should allow us to build
> >> programming languages that have a chance at being good enough, at
> >> least for our specific problem domain.
> >>
> >> (unquote)
> >
> >     Great quote.  Design patterns are an indication of where a
> >language lacks sufficient power.
>
> I agree. Design patterns are workarounds for language flaws.

Peter Norvig has a slide show which shows that in some languages,
most of the usual design patterns are either useless or invisible:
http://www.norvig.com/design-patterns/


--
Matthieu Villeneuve

Thomas Gagne wrote:

> > Hmmm.  There could be something to this.  We need Visitor because we
> > don't have multiple dispatch.  We need Command because we don't have
> > closures.  Etc, etc.
>
> I would think it wouldn't be too difficult to go through the populat
> patterns and indicate which are really "patterns" and which are
> work-arounds for language deficiencies.

.... and which are still genuine patterns but just embedded into the language
(or deeply into its libraries) -- for instance FactoryObject in Smalltalk.

Just because a pattern is part of a language doesn't make it any less of a
pattern; it just gives that pattern a different name and a different expression
in that language.  The design reasons for using a pattern will presumably be
identical whether or not that pattern has a native expression.  There may, of
course, be gains in any of (apparent) simplicity, homogeneity, or reliability,
if the pattern is native -- but that's just reducing the downside

I.e. the point (well) expressed earlier as "a design pattern is not a feature,
it's a bug" is, IMO, completely wrong-headed.

    -- chris

On Tue, 15 Feb 2005 11:34:29 -0000, Chris Uppal wrote:

> Thomas Gagne wrote:
> 
>>> Hmmm.  There could be something to this.  We need Visitor because we
>>> don't have multiple dispatch.  We need Command because we don't have
>>> closures.  Etc, etc.
>>
>> I would think it wouldn't be too difficult to go through the populat
>> patterns and indicate which are really "patterns" and which are
>> work-arounds for language deficiencies.
> 
> ... and which are still genuine patterns but just embedded into the language
> (or deeply into its libraries) -- for instance FactoryObject in Smalltalk.
> 
> Just because a pattern is part of a language doesn't make it any less of a
> pattern; it just gives that pattern a different name and a different expression
> in that language.  The design reasons for using a pattern will presumably be
> identical whether or not that pattern has a native expression.  There may, of
> course, be gains in any of (apparent) simplicity, homogeneity, or reliability,
> if the pattern is native -- but that's just reducing the downside
> 
> I.e. the point (well) expressed earlier as "a design pattern is not a feature,
> it's a bug" is, IMO, completely wrong-headed.

Whose bug, that's the question. I believe the point was that a pattern (any
pattern) is in some sense a "bug" in the language design. It is definitely
not one of the programmer who is using the pattern, at least not
necessarily. (:-)) Whether missing feature is a bug, well, popular patterns
are missing features that are needed much... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Mon, 14 Feb 2005 21:15:12 -0500, Thomas Gagne
<tgagne@wide-open-west.com> wrote:
> Robert C. Martin wrote:
>> On 14 Feb 2005 10:06:06 +0000, Patrick May <pjm@spe.com> wrote:
>> 
>> 
><snip>
>>>
>>>    Great quote.  Design patterns are an indication of where a
>>>language lacks sufficient power. 
>> 
>> 
>> 
>> Hmmm.  There could be something to this.  We need Visitor because we
>> don't have multiple dispatch.  We need Command because we don't have
>> closures.  Etc, etc. 
> 
> I would think it wouldn't be too difficult to go through the populat patterns 
> and indicate which are really "patterns" and which are work-arounds for 
> language deficiencies.

To say that is to say there's such a thing as a Perfect programming
language, or even a Perfect OO Programing language, neither of which I'm
willing to admit.

At least not until my computer has the Majel Barrett interface.

Thomas Gagne wrote:

> I would think it wouldn't be too difficult to go through the populat 
> patterns and indicate which are really "patterns" and which are 
> work-arounds for language deficiencies.

This has already been done. See

http://www.daimi.au.dk/~apaipi/workshop/nyartikel.pdf

-- 
mail1dotstofanetdotdk

"H. S. Lahman" <h.lahman@verizon.net> wrote in message 
news:t%9Qd.46050$QS5.21441@trndny06...
> Responding to Frebe...
>
> There aren't any "low-level" class libraries.  It doesn't matter where the 
> class comes from, all collaborations are peer-to-peer and there are no 
> hierarchical specification dependencies among classes.
>
How about a customer class and date class, say the customer class uses the 
date class to obtain a timestamp in one of its methods?  Surely you're not 
suggesting that a customer class and a date class have a peer to peer 
relationship?

Regards,
Daniel Parker 

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

>> Hmmm.  There could be something to this.  We need Visitor because we
>> don't have multiple dispatch.  We need Command because we don't have
>> closures.  Etc, etc.  
>> 
>> On the other hand, I refuse to believe that the perfect language ought
>> to be defined as one in which there are no repeating structures.  I
>> think every language will always be composable into patterns of use.
>
>Once old patterns became features of the programming languages new ones
>would appear at a higher abstraction level of new features...
>
>There will be an ever-growing hierarchy of languages of increasing power
>with some patterns on top of it.

For the most part, I agree with much of what people have said in this
thread.  A repeating pattern often indicates a design flaw *somewhere*.

However, is it a flaw in the language, or is it the lack of using a
generalized framework that handles this pattern elegantly for you?

In many cases, I think it is the latter.  Therefore, repeating the pattern
may be entirely wrong, but solving the pattern by creating generalized
frameworks may be a perfectly reasonable alternative than adding a feature
to the language that solves the problem.  Anytime you're adding a feature to
the language, I think you are starting to counter yourself in that now
you've created something language specific which is not general, and you're
heading in the wrong direction.

I believe in making languages as powerful and flexible as possible, in such
a way that the fault should always lie with the frameworks, and not the
language.  With languages like Smalltalk and Lisp, I think we are getting
much closer to that mark than some other languages.

I agree that patterns is an indication that there are design flaws
somewhere, but I don't think the fault is always with the language, but
often with frameworks or the lack of use of a generalized framework.
Perhaps sometimes it is a fault with the language, but not because it's
missing a feature to directly address the problem, but it's missing
something else fundamental *and general* that enables you to create a
framework that solves this pattern in an elegant way.

So the goal is this:

Design a language that is incredibly simple and yet ultimately powerful,
with the *minimum* amount of capabilities itself, whereby all the
capabilities lie in the frameworks.  Then create some frameworks that are
again incredibly simple yet ultimately powerful, with the minimum amount of
code and complexity.

Perhaps it's harder we might think, because with adding of every feature to
address a problem, you're increasing the complexity and countering your
end-goal.  This I think, becomes much more of a fine art than it is pure
logic, and everyone seems to have their own subjective take on what meets
those goals and what doesn't.

Ian

---
http://www.upright.net/ian/

Robert C. Martin wrote:

> Hmmm.  There could be something to this.  We need Visitor because we
> don't have multiple dispatch.  We need Command because we don't have
> closures.  Etc, etc.  

Yes, but how important is the difference in the real world? I have a 
feeling that replacing design patterns with marginally simpler language 
constructs is not going to be the next breakthrough in productivity.

Dagfinn Reiersol wrote:
> Robert C. Martin wrote:
> 
>> Hmmm.  There could be something to this.  We need Visitor because we
>> don't have multiple dispatch.  We need Command because we don't have
>> closures.  Etc, etc.  
> 
> 
> Yes, but how important is the difference in the real world? I have a 
> feeling that replacing design patterns with marginally simpler language 
> constructs is not going to be the next breakthrough in productivity.

A design pattern may be a work-around for the lack of closures, but it is 
*not* a "marginally simpler language construct..".

The difference in productivity of a languages supporting closures against 
those that do not is in closer's favor.  Lack of closures is why some 
languages must use iterators over collections and all the syntax and error 
they introduce during development.  That makes programmers less productive, 
and not marginally so.

There's a reason Java's inner- and related classes are awkward to learn, use, 
read, and document.  There's a reason Lisp and Smalltalk programmers love 
their lambdas and blocks.

Juha Laiho <Juha.Laiho@iki.fi> said:
>I've been trying my hand in programming Java for a while now, but have
>failed to see the "big" difference of what is procedural and what is OO
>programming until very recently (or this is how I currently feel).

....

Apologies for not taking part in the discussion I initiated, but other
things have pretty much kept me away from the keyboard for a while;

anyway, a big _THANK YOU_ to everyone; it seems I now have a few new
items on my reading list. I also have already now some clarification
to my confusion - and even though my initial view on the issue was
apparently far too narrow, I had managed to make some correct
observations.

So, thanks!
-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Juha Laiho wrote:
> Followups set to comp.object; apologies for disturbing
comp.lang.forth
> [SNIP]
>
> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on
this
> to any sensible shape.
> --
> Wolf  a.k.a.  Juha Laiho     Espoo, Finland
> (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M
V
>          PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++
y++++
> "...cancel my subscription to the resurrection!" (Jim Morrison)


OK, Wolf, you win!

In summary,

To /truly/ begin to see the light you must not fear the bottom up
approach.

Please take some time to look at machine forth(s).  ( F21, B16, C18 ...
)

What you will see is a /bear metal/ object oriented architecture that
forms complete absolute closure, ( yes, I know you can still /program/
non-closures, however, that is not he point. )

Message passing is a convenience , as are any other particular OO
conveniences expressed within a programming language.

OO Programming, as origninally defined, is a methodology by which
problems are decomposed into simpler components, thereby increasing
the understanding of the problem, OO is a solution, however, OO is
a methodology and not, neccesarily, characteristic of any programming
language, as such, ... maybe, other than one's own native tongue
expressing such problem decomposition.

Consider CSP/TimedCSP ( communicating sequential processes) as the
focus for your message passing understanding,  There is also a more
formal language for expressing a wide variety of OO decomposition
problems, The Z language.

mostly necessarily an OO systems software engineer or architect
/designer/ concern,

OO ( program development) example,

Tire object,
Road object,
Adhesion property negotiated between Tire and Road object.


Regards,

Mark A. Washburn

---

In comp.lang.forth the OT subject line should read as

OO programming - illumination!


Keep learning C/Java/Scheme, also.

Thomas Gagne wrote:
> Dagfinn Reiersol wrote:
> 
>> Robert C. Martin wrote:
>>
>>> Hmmm.  There could be something to this.  We need Visitor because we
>>> don't have multiple dispatch.  We need Command because we don't have
>>> closures.  Etc, etc.  
>>
>>
>>
>> Yes, but how important is the difference in the real world? I have a 
>> feeling that replacing design patterns with marginally simpler 
>> language constructs is not going to be the next breakthrough in 
>> productivity.
> 
> 
> A design pattern may be a work-around for the lack of closures, but it 
> is *not* a "marginally simpler language construct..".
> 
> The difference in productivity of a languages supporting closures 
> against those that do not is in closer's favor.  Lack of closures is why 
> some languages must use iterators over collections and all the syntax 
> and error they introduce during development.  That makes programmers 
> less productive, and not marginally so.

I knew someone would get me for this. ;-) I was referring to the 
specific example of the Command pattern without considering all other 
possible ways you could replace a design pattern with a language construct.

Iterators are much more pervasive than the Command pattern--in Java, 
anyway. So the potential difference in productivity is greater. In other 
words, you have a point.

I was thinking more in terms of what I would consider a normal use of 
design patterns. The way iterators are used in Java seems aberrant to me.

> 
> There's a reason Java's inner- and related classes are awkward to learn, 
> use, read, and document.  There's a reason Lisp and Smalltalk 
> programmers love their lambdas and blocks.

"Tom Dyess" <tdyess@dysr.com> wrote in message news:<PcMPd.5274$u16.806@bignews6.bellsouth.net>...
> OOP is basically objects of which have procedures, so for code to be OO
> doesn't mean it has to be devoid of procedural programming. Each object's
> method is a procedure, but the difference is that procedure is part of an
> object as opposed to just being a procedure sitting on it's own. The way OOP
> utilizes this is that each object is responsible for procedures that it can
> handle.

Basically, I never liked object oriented languages at all. Somehow it
seems wrong to assume  that everything is part of another, greater
thing that is totally encapsulated and has to take care of itself. If
the world was organized that way, a screw would either screw itself
into the wall or come with its own screwdriver.

As a matter of fact, when you look under the hood of an object, all
you see is a structure with a few pointers to functions. You don't
need an object oriented programming language to produce such code, C
will do just fine, thank you very much.

BTW, structures are not very efficient. A structure gives usually rise
to a frenzy of alignment  problems that can only be solved by fillers.
Actually, you really don't need structures, since it can also be
represented by a host of loosely related arrays. It doesn't make much
difference whether you write 'row.column' or 'column [row]', except
that arrays of the same type are much easier to handle for both the
compiler and the memory allocators.

Basically, there are only one-dimensional arrays or do you really
believe that by magic memory is wrapped into matrices and cubes? The
compiler conveniently translates your 'array [x] [y]' notations into
real offsets like 'array + ((x * size) + y)'.

There are a lot of fancy datatypes, but basically they are just arrays
of arrays. As a matter of fact, there are only two real datatypes, a
word and a byte. A pointer is usually a word. The different
pointertypes are just created to let the compiler do some work for
you, so you don't have to remember what the real size of e.g. a
character or an integer is. Thus, 'char* p + 1' can be translated into
'p + sizeof (char)'.

I wonder why people need a 'typeof()' operator: after all these
declarations in order to let the compiler do most of the work they
seem to have forgotten halfway what type 'p' actually was. After all
the help their object-oriented compiler gave them they have completely
lost track of what they were doing. So, if it doesn't help, what good
is it?

As a matter of fact (hush!) there is no such thing as a pointer. It's
just an address, in other words: it  is a variable that holds a
location in memory. A NULL pointer is just a variable that points to
the very first byte in memory (address 0) and by (compiler) convention
that is not a valid address. A NULL string is a pointer to a byte in
memory that just holds a terminator, which is 0 by convention. Note,
these are just conventions. You could define another convention which
may work just as well or even better.

Usually, I don't need much more than a stack (where I push my
parameters (all words)) and a way to allocate an array of words and
bytes. When I push a byte on the stack, it is expanded to a word and
when I store a value from the stack into a byte its 'most significant
bits' are lost. When I'm done, I terminate the allocation. I don't
need a paranoid garbage collector to clean up my mess, thank you. 
Even less, I don't need a compiler to do the 'instantiation' or
'destruction' of 'objects', I'm quite capable to allocate or
deallocate a bunch of bytes or words myself.

BTW, the latter seems a lot easier. Not only that, but my programs
seem to run a lot faster and are a lot smaller than most others. I can
forgave C that it was typed so I was forced to do some casts to get
rid of those ugly warnings. It still seems odd I have to prove a dumb
machine that I know what I am doing. The problem is that with C++ I
have to figure out what he is doing by using ugly things like class
browsers. Normally, I don't even need a debugger, so why the heck
should I use something as hideous as a class browser. When I'm really
in trouble the assembly switch of a C compiler does wonders, even
though most have forgotten it's in there.

The streams library of C++ is notoriously difficult to use. With a
file, you open it, dump a bunch of bytes there and close it. End of
story. A file handle is just another word. Most of the forth programs
I write professionally are between 25 and 150 lines long and written
in minutes, not hours. They do their job and are developed quicker
than even a C programmer can do. I recently wrote a program that
interfaces with Graphviz. It scans the Forth source file, dumps a .DOT
source file, which draws a graphic scheme of its call sequences. 150
lines, less than 1 hour hack. Most definitions are a line long (as
good Forth programs should). Try to beat me on that. And don't say
maintenance is a horror. It is not. Since most definitions are a line
long, it is easy to pinpoint what should be changed.

A compiler should be created humbly, not arrogantly. Why not: it's
there to help me; I forked out the bucks, so don't bug me. If it never
heard of a 'byte class' or a 'word class', it should follow some
classes, not me. And don't start to ask me for a 'constructor method':
if I didn't allocate it, I didn't need it and you don't have to
'construct' it for me.

Sometimes the world is not an object.. Better, if you look into
nature, there are plenty of networks, but few pure, natural
hierarchies. A hierarchy is a sub-class of a network anyway. Somehow,
it seems strange to me that people want to tackle 'real life problems'
with such limited tools.

Hans Bezemer

Hans Bezemer wrote:
> "Tom Dyess" <tdyess@dysr.com> wrote in message news:<PcMPd.5274$u16.806@bignews6.bellsouth.net>...
> 
>>OOP is basically objects of which have procedures, so for code to be OO
>>doesn't mean it has to be devoid of procedural programming. Each object's
>>method is a procedure, but the difference is that procedure is part of an
>>object as opposed to just being a procedure sitting on it's own. The way OOP
>>utilizes this is that each object is responsible for procedures that it can
>>handle.
> 
> 
> Basically, I never liked object oriented languages at all. Somehow it
> seems wrong to assume  that everything is part of another, greater
> thing that is totally encapsulated and has to take care of itself. If
> the world was organized that way, a screw would either screw itself
> into the wall or come with its own screwdriver.
> 
> As a matter of fact, when you look under the hood of an object, all
> you see is a structure with a few pointers to functions. You don't
> need an object oriented programming language to produce such code, C
> will do just fine, thank you very much.
> 
> BTW, structures are not very efficient. A structure gives usually rise
> to a frenzy of alignment  problems that can only be solved by fillers.
> Actually, you really don't need structures, since it can also be
> represented by a host of loosely related arrays. It doesn't make much
> difference whether you write 'row.column' or 'column [row]', except
> that arrays of the same type are much easier to handle for both the
> compiler and the memory allocators.
> 
> Basically, there are only one-dimensional arrays or do you really
> believe that by magic memory is wrapped into matrices and cubes? The
> compiler conveniently translates your 'array [x] [y]' notations into
> real offsets like 'array + ((x * size) + y)'.
> 
> There are a lot of fancy datatypes, but basically they are just arrays
> of arrays. As a matter of fact, there are only two real datatypes, a
> word and a byte. A pointer is usually a word. The different
> pointertypes are just created to let the compiler do some work for
> you, so you don't have to remember what the real size of e.g. a
> character or an integer is. Thus, 'char* p + 1' can be translated into
> 'p + sizeof (char)'.
> 
> I wonder why people need a 'typeof()' operator: after all these
> declarations in order to let the compiler do most of the work they
> seem to have forgotten halfway what type 'p' actually was. After all
> the help their object-oriented compiler gave them they have completely
> lost track of what they were doing. So, if it doesn't help, what good
> is it?
> 
> As a matter of fact (hush!) there is no such thing as a pointer. It's
> just an address, in other words: it  is a variable that holds a
> location in memory. A NULL pointer is just a variable that points to
> the very first byte in memory (address 0) and by (compiler) convention
> that is not a valid address. A NULL string is a pointer to a byte in
> memory that just holds a terminator, which is 0 by convention. Note,
> these are just conventions. You could define another convention which
> may work just as well or even better.
> 
> Usually, I don't need much more than a stack (where I push my
> parameters (all words)) and a way to allocate an array of words and
> bytes. When I push a byte on the stack, it is expanded to a word and
> when I store a value from the stack into a byte its 'most significant
> bits' are lost. When I'm done, I terminate the allocation. I don't
> need a paranoid garbage collector to clean up my mess, thank you. 
> Even less, I don't need a compiler to do the 'instantiation' or
> 'destruction' of 'objects', I'm quite capable to allocate or
> deallocate a bunch of bytes or words myself.
> 
> BTW, the latter seems a lot easier. Not only that, but my programs
> seem to run a lot faster and are a lot smaller than most others. I can
> forgave C that it was typed so I was forced to do some casts to get
> rid of those ugly warnings. It still seems odd I have to prove a dumb
> machine that I know what I am doing. The problem is that with C++ I
> have to figure out what he is doing by using ugly things like class
> browsers. Normally, I don't even need a debugger, so why the heck
> should I use something as hideous as a class browser. When I'm really
> in trouble the assembly switch of a C compiler does wonders, even
> though most have forgotten it's in there.
> 
> The streams library of C++ is notoriously difficult to use. With a
> file, you open it, dump a bunch of bytes there and close it. End of
> story. A file handle is just another word. Most of the forth programs
> I write professionally are between 25 and 150 lines long and written
> in minutes, not hours. They do their job and are developed quicker
> than even a C programmer can do. I recently wrote a program that
> interfaces with Graphviz. It scans the Forth source file, dumps a .DOT
> source file, which draws a graphic scheme of its call sequences. 150
> lines, less than 1 hour hack. Most definitions are a line long (as
> good Forth programs should). Try to beat me on that. And don't say
> maintenance is a horror. It is not. Since most definitions are a line
> long, it is easy to pinpoint what should be changed.
> 
> A compiler should be created humbly, not arrogantly. Why not: it's
> there to help me; I forked out the bucks, so don't bug me. If it never
> heard of a 'byte class' or a 'word class', it should follow some
> classes, not me. And don't start to ask me for a 'constructor method':
> if I didn't allocate it, I didn't need it and you don't have to
> 'construct' it for me.
> 
> Sometimes the world is not an object.. Better, if you look into
> nature, there are plenty of networks, but few pure, natural
> hierarchies. A hierarchy is a sub-class of a network anyway. Somehow,
> it seems strange to me that people want to tackle 'real life problems'
> with such limited tools.
> 
> Hans Bezemer
Without debunking most of everything you stated.
It's clear to me that you know nothing about OO concepts.
Especially the modelling part. Objects are all around you.
You yourself are an object composed on many organs, those
organs can be further modeled to include cells and so on and so forth.
Each organ has it's own respsonsiblity. An organ, when needed 
collaborates with other organs.

Are you getting any of this.

Oh, BTW.
The screw and it's ability to screw itself in.
Is just plane empty headed.

Hans Bezemer <hansoft@bigfoot.com> wrote:
> Basically, I never liked object oriented languages at all. Somehow it
> seems wrong to assume  that everything is part of another, greater
> thing that is totally encapsulated and has to take care of itself. If
> the world was organized that way, a screw would either screw itself
> into the wall or come with its own screwdriver.
> 
> As a matter of fact, when you look under the hood of an object, all
> you see is a structure with a few pointers to functions. You don't
> need an object oriented programming language to produce such code, C
> will do just fine, thank you very much.

That's not the issue here: OO is just another way of looking at the same
types of problems you can solve with "traditional" programming.


> BTW, structures are not very efficient. [...]

Very true. But with the availability of more and more menory, many feel
that memory efficiency is not that important anymore. Especially if you
note that while it is more efficient to model numbers as bytes, words,
etc. in terms of space, it is not in terms of processor efficiency: it
uses 32 bits exclusively, which is twice the size of a word.

Why is OO used then? Because it makes modelling and design easier.
Especially for complex problems. The result has not the smallest
footprint, not the fastest execution, but is _good_ _enough_.

However, large systems can be created faster, and that _saves_ _money_.
And in the end, it's the euros/dollars/<insert your currency here>
allocated by beancounters that determine what is being used.


-- 
Oscar Kind                                    http://home.hccnet.nl/okind/
Software Developer                    for contact information, see website

PGP Key fingerprint:    91F3 6C72 F465 5E98 C246  61D9 2C32 8E24 097B B4E2

Hans Bezemer wrote:
> "Tom Dyess" <tdyess@dysr.com> wrote in message news:<PcMPd.5274$u16.806@bignews6.bellsouth.net>...
> 
>>OOP is basically objects of which have procedures, so for code to be OO
>>doesn't mean it has to be devoid of procedural programming. Each object's
>>method is a procedure, but the difference is that procedure is part of an
>>object as opposed to just being a procedure sitting on it's own. The way OOP
>>utilizes this is that each object is responsible for procedures that it can
>>handle.
> 
> 
> Basically, I never liked object oriented languages at all. Somehow it
> seems wrong to assume  that everything is part of another, greater
> thing that is totally encapsulated and has to take care of itself. If
> the world was organized that way, a screw would either screw itself
> into the wall or come with its own screwdriver.

<snip>

I think everyone's taking Hans' post too seriously.  I don't think he meant it 
that way.  In the end he basically ended up suggesting FORTH and Assembly are 
all that's required.  I'm surprised he stopped when he did and didn't suggest 
that a little microcode is all anyone needs since that's where all the action 
is.  Anything above microcode is unnecessary fluff.  If the hardware weren't 
so restricting we would be able to assemble bits ourselves into groups however 
large we needed them without requiring those arbitrary 8, 16, 32, and 64-bit 
restrictions.

A little early for April Fools' Day, but this newsgroup is always in need of a 
  little levity, however dry or masked.

Hans Bezemer wrote:
> 
> "Tom Dyess" <tdyess@dysr.com> wrote in message news:<PcMPd.5274$u16.806@bignews6.bellsouth.net>...
> > OOP is basically objects of which have procedures, so for code to be OO
> > doesn't mean it has to be devoid of procedural programming. Each object's
> > method is a procedure, but the difference is that procedure is part of an
> > object as opposed to just being a procedure sitting on it's own. The way OOP
> > utilizes this is that each object is responsible for procedures that it can
> > handle.
> 
> Basically, I never liked object oriented languages at all. Somehow it
> seems wrong to assume  that everything is part of another, greater
> thing that is totally encapsulated and has to take care of itself. If
> the world was organized that way, a screw would either screw itself
> into the wall or come with its own screwdriver.

I snipped most of your comments but without prejudice. I do appreciate your thoughts.

I, too, am bothered by the hype surrounding OO. It is an amalgam of techniques that have 
been used successfully for a long time. In fact, Forth was one the first languages to 
effectively combine data and behavior with its BUILDS/DOES (and earlier) constructs. OO 
is no silver bullet, but it is an excellent technique ... I would call it the best 
modern programming facility by far.

I truly love Forth and have done some major development in the language including doing 
my own port to an oddball architecture. I learned a lot from Forth but am dismayed by 
its lack of traction in the mainstream. IOW, it's not often a practical solution in the 
real world.

> BTW, structures are not very efficient. A structure gives usually rise
> to a frenzy of alignment  problems that can only be solved by fillers.

I'm afraid you're behind the times. Java is very efficient because of the amazing 
strides made in runtime compiling/optimization. Alignment is not a consideration; Java 
doesn't even let you know if two members are stored adjacently. The compiler is free to 
use the most efficient organization.

I also really love Assembler and C. I've probably written far more assembly language 
systems than you will ever comtemplate. I would have no problem going back to those 
languages to develop systems (actually, I have, since I'm currently working on an ODBC 
driver). However, I also know I can produce more understandable/maintainable/bug-free 
systems in Java with greater ease.

I understand your stance that you want control and can handle it. I just don't see it as 
valid these days, in the general case. It's a waste of development resources. My first 
programming was all in machine code, because I didn't want to cede any control to the 
assembler. I'm much smarter now ;^)

-- 
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)

Reply7471859353@wmconnect.com wrote:
>
> Please take some time to look at machine forth(s).  ( F21, B16, C18
....
> )

The formula SMP MPP FORTH VLIW didn't have a name like F21, B16, C18
....
But was/is 16-bit instruction ( with an optional provision
for a packed 5-bit set , ARM similar but more like model from Inmos
Transputer F code instrustion with 31 (0,reserved) dynamic local
methods. )

PLEASE WRITE 100,000 PAGES OF IBM DEFENSE DOCUMENTATION THAT
EXHAUST ALL SUB-ITERATIONS OF THE COUPLE HUNDERED I SENT THEM.

>
> OO ( program development) example,
>
> Tire object,
> Road object,
> Adhesion property negotiated between Tire and Road object.
>
>
> Regards,
>
> Mark A. Washburn
>
> ---
>
> In comp.lang.forth the OT subject line should read as
>
> OO programming - illumination!
> 
> 
> Keep learning C/Java/Scheme, also.

kjc wrote:
> Hans Bezemer wrote:
> 

>> Sometimes the world is not an object.. Better, if you look into
>> nature, there are plenty of networks, but few pure, natural
>> hierarchies. A hierarchy is a sub-class of a network anyway. Somehow,
>> it seems strange to me that people want to tackle 'real life problems'
>> with such limited tools.
>>
>> Hans Bezemer
> 
> Without debunking most of everything you stated.
> It's clear to me that you know nothing about OO concepts.
> Especially the modelling part. Objects are all around you.
> You yourself are an object composed on many organs, those
> organs can be further modeled to include cells and so on and so forth.
> Each organ has it's own respsonsiblity. An organ, when needed 
> collaborates with other organs.
> 
> Are you getting any of this.
> 
> Oh, BTW.
> The screw and it's ability to screw itself in.
> Is just plane empty headed.

Sorry, but Hans view is just right. an object oriented view of the
model is not the only one. I prefere the simplest possible one - and the
object oriented view by far isn't the simplest one. OO modeling
ends in myriads of classes and methods, only manageable with highly
sophisticated browsers. the last 10 years I have developed large
Smalltalk and Java applications. Smalltalk is fun, Java isn't.
since performance was sometime an issue I had rewritten some
applications in C. those rewrites were an order of magnitude
smaller and three orders of magnitude faster. not that JIT
compilers in Smalltalk (or even in Java) will produce slow code
- it's just the oposite.

As Hans mentioned, applications written in Forth become even simpler.
Complexity from high to low:  Smalltalk -> C -> Forth.
at least IMO

--
best wishes
Andreas Klimas

Oscar kind wrote:
> Hans Bezemer <hansoft@bigfoot.com> wrote:
> 
>>Basically, I never liked object oriented languages at all. Somehow it
>>seems wrong to assume  that everything is part of another, greater
>>thing that is totally encapsulated and has to take care of itself. If
>>the world was organized that way, a screw would either screw itself
>>into the wall or come with its own screwdriver.
>>
>>As a matter of fact, when you look under the hood of an object, all
>>you see is a structure with a few pointers to functions. You don't
>>need an object oriented programming language to produce such code, C
>>will do just fine, thank you very much.
> 
> 
> That's not the issue here: OO is just another way of looking at the same
> types of problems you can solve with "traditional" programming.
> 
> 
> 
>>BTW, structures are not very efficient. [...]
> 
> 
> Very true. But with the availability of more and more menory, many feel
> that memory efficiency is not that important anymore. Especially if you
> note that while it is more efficient to model numbers as bytes, words,
> etc. in terms of space, it is not in terms of processor efficiency: it
> uses 32 bits exclusively, which is twice the size of a word.
> 
> Why is OO used then? Because it makes modelling and design easier.
> Especially for complex problems. The result has not the smallest
> footprint, not the fastest execution, but is _good_ _enough_.
> 
> However, large systems can be created faster, and that _saves_ _money_.

this is simply _not_ true. I have seen too many evidences against this
hypothesis.

> And in the end, it's the euros/dollars/<insert your currency here>
> allocated by beancounters that determine what is being used.

wrong again. if developers want to be competitive they have
to learn keeping things simple. but in the UML/CASE and OO
world this just isn't possible. too many self produced problems.
IT becomes the costumer.

--
best wishes
Andreas Klimas

Andreas Klimas wrote:
> wrong again. if developers want to be competitive they have
> to learn keeping things simple. but in the UML/CASE and OO
> world this just isn't possible. too many self produced problems.
> IT becomes the costumer.

There's no real surprise here. All early industries are known to have huge
internal costs, and little external ones. The cotton industry in Manchester
had 95% internal costs (steam engines, cotton mills, spinneries, automatic
looms, etc.), most of that machine costs, not direct manpower costs. The
machine costs certainly were manpower costs, too, but externalized manpower
(someone had to build the machines, dig out the coal and so on). Over the
time, the internal friction is removed, and the internal costs drop. ATM, I
think the cotton industry is dominated by external costs at the sales side.

Now, the cotton industry had 200 years to mature, the IT industry didn't.
Perhaps it's also paying not enough to the sales channel. "Keep it simple"
often has problems to sell, and "Keep it compatible" is easier to sell.
With "Keep it compatible", you accumulate a huge legacy, and you have to
pay the price for that.

But most of the time, the IT industry implements complexity for it's own
sake. Complexity seems to be a selling point - "we have XXX, YYY, and ZZZ",
without questioning if all that is necessary. "OOP" is just another of
those selling points, due to the hype around it. Sometimes it's necessary,
sometimes it isn't. It's no silver bullet, but it has something to offer.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Andreas Klimas <klimas@klimas-consulting.com> wrote:
> Oscar kind wrote:
>> Why is OO used then? Because it makes modelling and design easier.
>> Especially for complex problems. The result has not the smallest
>> footprint, not the fastest execution, but is _good_ _enough_.
>> 
>> However, large systems can be created faster, and that _saves_ _money_.
> 
> this is simply _not_ true. I have seen too many evidences against this
> hypothesis.

Please enlighten me with examples then. I'd like to correct myself if I'm
wrong, but I need something to replace my current knowledge with.

Also, were the correct techniques being used? Using OO to implement a
process centric solution, for example, is a mistake. As is using a procedural
approach to implement a data centric solution.


>> And in the end, it's the euros/dollars/<insert your currency here>
>> allocated by beancounters that determine what is being used.
> 
> wrong again. if developers want to be competitive they have
> to learn keeping things simple. but in the UML/CASE and OO
> world this just isn't possible. too many self produced problems.
> IT becomes the costumer.

Keeping things simple is the most difficult thing by far (IMHO). This is
not related to the specific technique used, although some techniques make
is easier to keep things simple. For administrative systems (my area of
expertise), I find OO does this.

This does not negate the fact however, that developers only work on stuff
as a hobby, or what they get paid for. And for this last part, a developer
has no final authority. He only has as much influence as his manager gives
him, which hopefully increases by his/her skills in making things simple.

However, if a manager has the idea that OO makes life easiest (even if it's
misplaced), then that's what is being used.


-- 
Oscar Kind                                    http://home.hccnet.nl/okind/
Software Developer                    for contact information, see website

PGP Key fingerprint:    91F3 6C72 F465 5E98 C246  61D9 2C32 8E24 097B B4E2

"I think everyone's taking Hans' post too seriously. I don't think he
meant it
that way."

I've taken a few quotes from previous posts. First, I want to debunk
the myth that this was just flame-bait. Ok, it was a little over the
top, true, but certainly no flame-bait.. And I wasn't kidding either..

"Sorry, but Hans view is just right. an object oriented view of the
model is not the only one. I prefere the simplest possible one - and
the
object oriented view by far isn't the simplest one. OO modeling
ends in myriads of classes and methods, only manageable with highly
sophisticated browsers."

Right, that is my experience too. And I'm sick and tired of trying to
cram a simple problem into a flawed paradigm. What most people seem to
forget is that OO is a _programming_technique_, not a "one fits all"
model. I use OO techniques in my programs too if I want (or need) to
do abstraction. Yes, in C. You can easily do that. X was written that
way and Axel-Tobias Schreiner wrote a whole
book on that subject in 1993.

Sometimes things are not simpler than they are. This little piece of
code parses a textfile. Tell me where OO helps. Tell the file it has
to parse and rewrite itself? What does that help? This thing is only
70 lines (including comment).

: Field> bl parse-word ;               ( -- a n)              
: Fields>> 0 do Field> 2drop loop ;    ( n --)
: Lines>> 0 do refill drop loop ;      ( n --)

: GetCard                              ( --)
  2 Fields>> Field> Card place         \ skip two fields, get card
number
  2 Fields>> Field> Phone place        \ skip two fields, get phone
number
  3 Lines>>                            \ skip three lines
;

"I, too, am bothered by the hype surrounding OO. It is an amalgam of
techniques that have been used successfully for a long time. In fact,
Forth was one the first languages to effectively combine data and
behavior with its BUILDS/DOES (and earlier) constructs. OO is no
silver bullet, but it is an excellent technique ... I would call it
the best modern programming facility by far."

But even that can be taken too far. When very complex datatypes are
developed you sometimes find yourself wondering what this thingy does
again.. Sometimes I rather prefer to write a word that does an
explicit conversion, just to remind myself I took the address of a
CREATEd item and converted it to something much more complex.

OO can be useful in some instances, but most of the time it is too
limited and horrifying designs emerge to to make it fit. Lego stones
(Forth) are much more convenient. If it fits, you can slam them
together and let the data pass by itself. Even distinct datatypes
don't help much, except add more conversion. If you want easily
maintainable code, factor and make small routines and small programs.
If you need monstrous amounts of code to write a single function,
routine or program you're doing something wrong. Let systems
communicate, don't try to cram all and everything in a single program.

Wording is very important. I've shown more than once that you can tell
the computer a story while actually writing Forth code.

"You yourself are an object composed on many organs, those
organs can be further modeled to include cells and so on and so forth.
Each organ has it's own respsonsiblity. An organ, when needed 
collaborates with other organs."

Someone doesn't know to much about biology, I'm afraid. For the
stratification you mention is fairly artificial and arbitrary. The
pancreas, for example, has two distinct functions and two very
different kind of cells. There are a lot of tissues that do not
distinctly belong to any organ. Mitochondria are very independent cell
organs with their own DNA. Cut up a human and you'll see that
everything is not so distinct as your biology books try to make you
believe. FYI, I have a BA in biology, so I know what I'm talking
about.

Hans

Dagfinn Reiersol wrote:
> Thomas Gagne wrote:
> > Dagfinn Reiersol wrote:
> >
> >> Robert C. Martin wrote:
> >>
> >>> Hmmm.  There could be something to this.  We need Visitor because
we
> >>> don't have multiple dispatch.  We need Command because we don't
have
> >>> closures.  Etc, etc.
> >>
> >>
> >>
> >> Yes, but how important is the difference in the real world? I have
a
> >> feeling that replacing design patterns with marginally simpler
> >> language constructs is not going to be the next breakthrough in
> >> productivity.
> >
> >
> > A design pattern may be a work-around for the lack of closures, but
it
> > is *not* a "marginally simpler language construct..".
> >
> > The difference in productivity of a languages supporting closures
> > against those that do not is in closer's favor.  Lack of closures
is why
> > some languages must use iterators over collections and all the
syntax
> > and error they introduce during development.  That makes
programmers
> > less productive, and not marginally so.
>
> I knew someone would get me for this. ;-) I was referring to the
> specific example of the Command pattern without considering all other

> possible ways you could replace a design pattern with a language
construct.
>
> Iterators are much more pervasive than the Command pattern--in Java,
> anyway. So the potential difference in productivity is greater. In
other
> words, you have a point.
>
> I was thinking more in terms of what I would consider a normal use of

> design patterns. The way iterators are used in Java seems aberrant to
me.
>
> >
> > There's a reason Java's inner- and related classes are awkward to
learn,
> > use, read, and document.  There's a reason Lisp and Smalltalk
> > programmers love their lambdas and blocks.

pattern question?  ( FORTH -> C/JAVA => SCHEME/LISP )  VON NEWMAN

BOOK MARK THIS LINK

http://groups-beta.google.com/groups?q=&start=0&scoring=d&enc_author=G4YumhIAAAA0qQiEMNXvzco-t51HUQzYrjcvJMYp3afiZB9NxWdHgA&

AND/OR THIS LINK

http://mywebpage.netscape.com/mawcowboy/homepage.html

Hans Bezemer wrote:

> What most people seem to forget is that OO is a
> _programming_technique_, not a "one fits all"
> model.

You might not want to lump most everyone who uses some object
techniques into that category.  Especially in a Forth forum
where OOP is used as an *extension* to Forth, not as a *replacement*
for Forth.



> I use OO techniques in my programs too if I want (or need) to
> do abstraction. Yes, in C. You can easily do that. X was written that
> way and Axel-Tobias Schreiner wrote a whole
> book on that subject in 1993.
>
> Sometimes things are not simpler than they are. This little piece of
> code parses a textfile. Tell me where OO helps.

Make up your mind.  First you say you use OOP if you want and
then you slam it.  ??  Give it a rest guy.  I don't think there
is quite the amount of "hype" over OOP as you suggest.  At
least not in Forth circles.  Why does this topic bother you?

Choose your tool and program in peace.

Regards,

-Doug

Doug Hoffman wrote:
> Hans Bezemer wrote:
>
> > What most people seem to forget is that OO is a
> > _programming_technique_, not a "one fits all"
> > model.
>
> You might not want to lump most everyone who uses some object
> techniques into that category.  Especially in a Forth forum
> where OOP is used as an *extension* to Forth, not as a *replacement*
> for Forth.
>
>
>
> > I use OO techniques in my programs too if I want (or need) to
> > do abstraction. Yes, in C. You can easily do that. X was written
that
> > way and Axel-Tobias Schreiner wrote a whole
> > book on that subject in 1993.
> >
> > Sometimes things are not simpler than they are. This little piece
of
> > code parses a textfile. Tell me where OO helps.
>
> Make up your mind.  First you say you use OOP if you want and
> then you slam it.  ??  Give it a rest guy.  I don't think there
> is quite the amount of "hype" over OOP as you suggest.  At
> least not in Forth circles.  Why does this topic bother you?
>
> Choose your tool and program in peace.
>
> Regards,
>
> -Doug

WARNING: Failure to perform the following instructions
may lead to misunderstanding,

Maybe start simple,


Reply7471859353@wmconnect.com wrote:
>
> OO ( program development) example,
>
> Tire object,
> Road object,
> Adhesion property negotiated between Tire and Road object.
>
>
> Regards,
>
> Mark A. Washburn
>
> ---
>
> In comp.lang.forth the OT subject line should read as
>
> OO programming - illumination!
>
>
> Keep learning C/Java/Scheme, also.


Then, continue your search using the following view

http://groups.google.com/groups?q=group:comp.*+insubject:oo+insubject:programming+insubject:illumination&start=0&scoring=d&hl=en&lr=&ie=UTF-8&safe=off&num=100&as_drrb=b&as_mind=1&as_minm=1&as_miny=1981&as_maxd=31&as_maxm=12&as_maxy=2005&filter=0

Regards,

Oscar kind wrote:
> Andreas Klimas <klimas@klimas-consulting.com> wrote:
> 
>>Oscar kind wrote:
>>
>>>Why is OO used then? Because it makes modelling and design easier.
>>>Especially for complex problems. The result has not the smallest
>>>footprint, not the fastest execution, but is _good_ _enough_.
>>>
>>>However, large systems can be created faster, and that _saves_ _money_.
>>
>>this is simply _not_ true. I have seen too many evidences against this
>>hypothesis.
> 
> 
> Please enlighten me with examples then. I'd like to correct myself if I'm
> wrong, but I need something to replace my current knowledge with.

there is no enlightenment at all. just experience:

1. project starts out with a framework (say JSP/J2EE)
2. JSP/J2EE seems too complicated so as a next step a
    new framework would be developed which of course didn't
    replace the other one.
3. A company wide architecture will be released which
    ends in a new couple of libraries - on top of the
    second framework.
4. now real requirement come in this play - which of
    course doesn't fit (well) in those frameworks and architectures.
    so we have to work around and hope that we get
    those requirements running. but at this time we
    have to deal with so many problems - released only
    by 'framework developers' and 'senior architects'

well, with all that stuff we need about three weeks to
develop an new simple HTML Form.
to start the application it needs some hours and 16GB
of RAM. Response time approx. 3 min.

I have seen the exact same approach on a couple
of very big customers in Swiss and Germany.

My Solution:
Simple Web Server (essentialy HTTP protocol handler)
written in C.200 lines of code written in two hours.
Application written in C, very sharp, only real needed
requirement included. no dynamic behavior. written in
some weeks. 10000 lines of C code. (compared by 150000
lines of Java code). 512 MB Ram (compared by 16GB).


believe it or not.
most time spent is not development, it's in understanding
of the problem domain. once one has grasped the requirement,
implementation is easy. Now some hints
-> minimize runtime exceptions (out of memory, of
    disk space, TCP errors etc.)
-> minimize the use of frameworks, the minimum is zero
-> avoid implementing hooks for future extensions
-> use a straight implementation for the real problem (business
    problem).
-> don't avoid thinking.

.... and so on

> Keeping things simple is the most difficult thing by far (IMHO). This is
> not related to the specific technique used, although some techniques make
> is easier to keep things simple. For administrative systems (my area of
> expertise), I find OO does this.

the problem I see (nearly every day) is that peoples are more
interested in writing techincally correct and pretty OO code
than in solving the real problem. as I mentioned above, this
will end in myriads of classes and methods, by far too oversized
for given problems. well I see, is much more fun to play
the technical game.

one question:
how many classes / methods are needed to convert a currency
into another ?

> 
> This does not negate the fact however, that developers only work on stuff
> as a hobby, or what they get paid for. And for this last part, a developer
> has no final authority. He only has as much influence as his manager gives
> him, which hopefully increases by his/her skills in making things simple.
> 
> However, if a manager has the idea that OO makes life easiest (even if it's
> misplaced), then that's what is being used.

sorry again. if software development becomes too expensive, managers
decide to outsource them, for example to india - no joke !
and anyway, those peoples do exact the same job, only three times
cheaper.

best wishes
Andreas Klimas

Responding to Frebe...

>>There aren't any "low-level" class libraries.  It doesn't matter where 
>>the class comes from, all collaborations are peer-to-peer and there are 
>>no hierarchical specification dependencies among classes.
> 
> 
> If there are no "low-level" class libraries, there are no "low-level"
> functions. Please explain why it is no hierachical dependencies in
> methods specifications, like in function specifications. The only
> difference between a function and a method is that the function is
> bundled together with a class and can access an object state.

Once again, it is about how the method is specified, not the mechanics 
of procedures.

ClassX::doIt(x)
    tmp = x + 5;
    tmp = myClassB->doIt(tmp);
    tmp = tmp * 2;
    this->attr1 = myClassC->doIt(tmp);

 From an OOA/D viewpoint this is a terrible method because one cannot 
specify what ClassX::doIt() should do without also specifying what 
ClassB::doIt() and ClassC::doIt() do.  Nor can one unit test 
ClassX::doIt() without correct implementations of those functions.

However, remove the class boilerplate and this is a typical function for 
a higher level node in a functional decomposition tree.  The 
specification of the outer doIt is hierarchically dependent on the 
specifications of the lower level functions it invokes.

In an OO application one would correct this situation by decomposing the 
responsibility until it was self-contained:

ClassX::doIt(x)
     tmp = x + 5;
     myClassB->doIt(tmp);

ClassX::setAttr1(x)
     this->attr1 = x;

Now ClassB::doIt() would invoke ClassC::doIt() and ClassC::doIt() would 
invoke ClassX::setAttr1().  That peer-to-peer daisy chaining completely 
eliminates the hierarchical dependency.

One can now fully unit test ClassX::doIt() by demonstrating that it 
called ClassB::doIt() with the correct argument without implementing 
ClassB::doIt().  That's because ClassB::doIt() no longer returns a value 
that CLassX::doIt uses.  So ClassX::doIt() is completely indifferent to 
what ClassB::doIt() does.

Perhaps more important, ClassX has no idea that ClassC::doIt() needs to 
be executed after ClassB::doIt() in the overall solution's flow of 
control.  It is that independence from the overall problem solution flow 
of control that defines self-containment for OO responsibilities.

>>>I think that collaborations between functions can be defined as "on
>>>peer-to-peer basis" too.
>>
>>Not if the function's specification includes the specification of
>>functions that it invokes hierarchically.
> 
> 
> But this is the same for method specifications.

Only for methods defined via bad OOA/D (i.e., their behavior 
responsibilities not logically indivisible at the given level of 
abstraction and/or they are not self-contained).

>>>How is messages separated from methods in C++ or Java?
>>
>>I said "OOA/D".  The OOPLs are inherently procedural because they are 
>>3GLs and there is no separation of message and method during OOP.
> 
> 
> This thread started with a discussion about OO programming, not about
> A/D. If the focus on programming and not A/D, doesn't method
> specifications have hierachical dependencies in the same way as
> functions?

No.  In the example above once the method is self-contained it doesn't 
matter that the message is executed via a procedure call at the 3GL 
level.  The dependency on what the callee does has been eliminated.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Responding to Parker...

>>There aren't any "low-level" class libraries.  It doesn't matter where the 
>>class comes from, all collaborations are peer-to-peer and there are no 
>>hierarchical specification dependencies among classes.
>>
> 
> How about a customer class and date class, say the customer class uses the 
> date class to obtain a timestamp in one of its methods?  Surely you're not 
> suggesting that a customer class and a date class have a peer to peer 
> relationship?

Maybe; maybe not.  B-)  The Date would probably be a dumb data holder. 
Somebody else would have to understand the context where a new timestamp 
was required, invoke the OS service to get it, and update the Date 
object via a setter.

Suppose it is a client of Customer that logically understands the 
timestamp update rules.  Now at the OOA level one might have:

[Client]
     | 1
     |
     |
     | *
[Customer]
  + Date

In this case Customer::Date is a knowledge attribute so it can be 
accessed via Customer::setDate(timestamp) directly.  Now [Date] is 
simply a scalar ADT.  The peer-to-peer collaboration is between [Client] 
and [Customer].

However, let's suppose [Date] is not a scalar ADT; instead it is a class 
with distinct attributes like {Month, Day, Year, Hour, Minute, Second} 
that are otherwise important to the problem in hand.  Now [Date] can't 
be an attribute ADT in Customer at the OOA level because it is not a 
simple data domain.  Now we have to have:

[Client]
     | 1
     |
     |
     | *
[Customer]
     | 1
     |
     |
     | 1
   [Date]
   + Year
   + Month
   ...

Now [Date] is a unique entity that has a relationship with [Customer]. 
In addition, [Client] now has a peer-to-peer collaboration with [Date] 
because it must decompose the timestamp into the [Date] attributes.  So 
[Client] must navigate through [Customer] to [Date].

During OOD one may determine that [Customer] and [Date] have a 
whole/part relationship and the [Date] life cycle is tied to that of 
[Customer], so one may designate the relationship as a composition 
association.  During OOP one may decide to optimize data integrity for 
that life cycle dependency by embedding [Date] in [Customer] and 
providing an interface in [Customer] that [Client] can access to set 
Year, Month, etc.

That's fine, but it makes the application less robust in the face of 
change.  That's because [Date] is a delegation at the OOA level but the 
OOP optimization has made the [Date] properties part of the [Customer] 
interface.  That will present a problem if the relationship between 
[Customer] and [Date] changes so their life cycles are no longer 
dependent.  (Admittedly a stretch in this example.)  Not only will the 
implementation of [Customer] change; so will the implementation of the 
[Client] that accesses the [Date] properties <now incorrectly> through 
the [Customer] interface.

Bottom line: Yes, there are situations where [Date] and [Customer] have 
a relationship and [Client] has a peer-to-peer collaboration with 
[Date], at least at the OOA level.  One sacrifices that OOA purity at 
the OOP level only at the peril of making the application less 
maintainable.  IOW, the OOA forces the developer to think about things 
because the sacrifice needs to be explicitly justified at the OOP level.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

H. S. Lahman wrote:
> The two most fundamental (of many) differences between OO development
> and procedural development are the elimination of hierarchical
> implementation dependencies

This is your original claim. But later you show that it OO code may
have hierachical dependencies too. Eliminating hierachical dependencies
using a messaging mechanism would be possible in procedural development
too, wouldn't it?

I develop message-driven applications too. This approach is useful for
GUI logic and inter-application communication. But I can't see how it
could be used everywhere. In your example you only show how to rewrite
a method (ClassX::doIt) that from the start didn't return any value.
Lets have at look at a fragment of the Date class.

class Date
  boolean after(Date)  // Tests if this date is after the specified
date.
  boolean before(Date) //  Tests if this date is before the specified
date.

Lets say I have a method myMethod in MyClass like this:

MyClass::myMethod(date1, date2)
  if (date1.after(date2))
    print date1
  else
    print date2

How can hierachical dependecies be removed using messages in this
scenario?

> > But this is the same for method specifications.
> Only for methods defined via bad OOA/D
Where can I find the definition of "good" and "bad" OO? First you claim
OO to be better than procedural in one aspect. Now you say that only
"good" OO is better than procedural. If that statement should have any
validity at all, some sort of definition of "good" need to be done.

Fredrik Bertilsson
http://butler.sourceforge.net

"Doug Hoffman" <dhoffman@talkamerica.net> wrote in message news:<1108766302.602474.22130@o13g2000cwo.googlegroups.com>...
> You might not want to lump most everyone who uses some object
> techniques into that category.  Especially in a Forth forum
> where OOP is used as an *extension* to Forth, not as a *replacement*
> for Forth.
Fortunately. FYI, I didn't start this topic. I'm just giving my
reaction under the first amendement. ;-)

> > I use OO techniques in my programs too if I want (or need) to
> > do abstraction. Yes, in C. You can easily do that.
> Make up your mind.  First you say you use OOP if you want and
> then you slam it.?? 
No, I use OOP as a technique. Like lookup tables, calculation, and any
other programming technique or algorithm you can think of. That
doesn't mean I find every problem suitable to be solved by using OOP.
In other words, I got nothing against OOP, I just don't find it the
right paradigm for EVERY problem:

    this->add (this->value);

Is simply less clear and evident than:

    a += a;

Or even:

    a dup @ swap +!

> Why does this topic bother you?
> Choose your tool and program in peace.
When making money, it is not always up to me to choose my tool. And
working around the limitations or making procedural interfaces around
OOP just plain gets me down. I wanna do something useful with my time.
Even when working.

Hans

In article <eaef3280.0502210425.3f75448b@posting.google.com>,
 hansoft@bigfoot.com (Hans Bezemer) wrote:

> In other words, I got nothing against OOP, I just don't find it the
> right paradigm for EVERY problem:
> 
>     this->add (this->value);
> 
> Is simply less clear and evident than:
> 
>     a += a;
> 
> Or even:
> 
>     a dup @ swap +!

Umm, what has choice of syntax got to do with OOP?

How many of the people on this thread arguing against "OOP" are arguing 
against a particular message-oriented and awkward syntax?

For example, a += a; could very well be implemented in C++ using 
(horrors) OOP!

-- 
Andy Dent BSc  MACS  AACM   http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability

In article <37q5i9F5f5j9kU1@individual.net>, klimas@klimas-
consulting.com says...

believe it or not

(SNIP)

I strongly agree that the biggest problem is understanding the problem 
domain.  I was hoping that OOP and UML would shorten the time needed for 
understanding, and here is my current set of assumptions, subject to 
change as I get smarter:

1. Programmers should learn to solve problems before they impose their 
solutions on others.  In business, a problem is defined as the 
difference between the way things are and the way you would like them to 
be.  Important is the scope, timing and location of the problem 
elements.  In programming, a problem is more like a problem in 
mathematics where we are looking for a series of behaviors that lead to 
a desired goal.  However, since the first iteration seldom leads cleanly 
to the desired results, go back to identifying scope, location and 
timing to understand why not.

2. Use case forms and diagrams can greatly improve the understanding of 
the goals of the system, especially if the system analyst/programmer is 
not fully involved in the field of expertise involved.  I've been 
through dozens of approaches to using UML, and I finally hit on a book 
called, "Tried and True Object Development" by Aalto, et al., which 
finally made sense to me.  I am now willing to spend lots of up-front 
time getting all the use case forms I can imagine filled in before 
trying to develop the system.  Of course, going back to the business 
problem "scope" parameter, I believe it's very important to determine as 
many desirable and undesirable effects as possible and design the 
appropriate behaviors for the system.

3. If you don't understand propositional logic, you probably don't 
understand the problem domain.  I doubt that anyone is going to parse 
the whole system for validity, but prop. logic is an underused tool for 
sub-domain problem-solving. Objects should be logically consistent.

4. Nobody really programs but the programmer.  I'm a big fan of first- 
or second-draft code generation from Rational Rose or similar tools, but 
the tools are not sufficient for elegant systems.  When I first learned 
to program back in 1965, we did a flowchart, then coded from the 
flowchart (an assembly language called AUTOCODER...isn't THAT funny!). I 
still like the process of building from a blueprint.

I've found my way back to Smalltalk because Smalltalk suits my 
thinking/programming style better than most languages do, but I'm multi-
lingual, and I have developed craft in other languages such as VB, C++ 
and Java so I'm able to speak the language of the country I'm in, and 
still successfully develop strong apps and systems.

There are still situations where straight assembly language programming 
is superior to high-level languages. I generally use decision tables 
instead of flowcharts these days, but the use case forms are still VERY 
helpful in understanding the problem.

For OOP, the patterns on
 http://www.object-arts.com/EducationCentre/Patterns/PatternIndex.htm
are very helpful.  Why re-invent the wheel?  This page was helpful in 
developing patterns for my other languages, also.

This has been a long post.  I hope it's useful to someone else, but I'm 
grateful that I can share my opinions with others in this group.

Mike

Hans Bezemer wrote:

> > > I use OO techniques in my programs too if I want (or need) to
> > > do abstraction. Yes, in C. You can easily do that.

> > Make up your mind.  First you say you use OOP if you want and
> > then you slam it.??

> No, I use OOP as a technique. Like lookup tables, calculation, and
any
> other programming technique or algorithm you can think of. That
> doesn't mean I find every problem suitable to be solved by using OOP.
> In other words, I got nothing against OOP, I just don't find it the
> right paradigm for EVERY problem:

Go back and reread my post.  Nowhere did I suggest that you or I or
anyone should either not use OOP at or use it for everything.  I, like
you, suggest that there might be a middle road.  Apparently we do agree
on that.

Regards,

-Doug

[Removed cl.forth, added and set F'up2 to comp.object]

  I didn't follow the (predictably) ensuing flame war closely, so I'm not
sure if this has been addressed. If it has, I apologize, but I didn't see
it. And sorry I'm a bit late in this.

In message <PcMPd.5274$u16.806@bignews6.bellsouth.net>,
Tom Dyess wrote on Sun, 13 Feb 2005 12:36:26 -0500:

[...]
>> The Smalltalk style appears to me to be build on very long (Contrasting
>> to Java) message chains, which begin by building some new object, then
>> doing numerous pieces of small-scale processing on that object (and in
>> the end perhaps/often returning a completely different object than was
>> originally created). I think I've seen a reference to "message-passing
>> OO" somewhere.
> 
> I know absolutely nothing about SmallTalk, but this seems very strange to
> me. Are you talking about inheritance?

  No, message-passing is a customary generic OO term for describing the
interaction between objects. They send each other messages. Since message
passing has had some other connotations for quite some time that aren't
necessarily supposed to be implied by the term in OO, Jacobson for
example prefers to speak of stimuli (no idea if that alternative has been
widely accepted in the OO community). What it comes down to is that you
trigger some behavior in the receiving object, whether you say by sending
it a message or by giving it a stimulus.

  In the context of Java, a method call is a message/stimulus. Returning
something to the caller of a method is a message/stimulus. Throwing an
exception is a message/stimulus.

  I think this generic terminology is often employed to emphasize the
decoupling of message sender and receiver achieved through polymorphism,
abstraction and encapsulation (in varying proportions).

[...]
>> - a lot of avoidable local variables used (references to which could then
>>  be accidentally leaked somewhere, and thus be ineligible for garbage
>>  collection)
> 
> You should always define variables in the lowest scope possible. There is
> nothing wrong with local variabes, on the contrary, it's bad form to have a
> bunch of global variables, but you will probably always have them, just try
> to keep them to a minimum. For example, in a servlet, I keep my DB
> connection/pool in a global scope in the servletContext. It doesn't make
> sense to create them locally.
[...]

  What you say is true, but I think he wasn't referring to local
vs. global variables at all. Instead, I think he meant the proliferation
of method-local variables that serve no other purpose than to be able to
call a method on (send a message to ;-) ) that object, when a cleaner
design would have the object the reference originated from delegate
correctly instead. To illustrate:

Compare and contrast

A a = registry.getSomeA( x ); // just to get started somewhere
B b = a.getB();
C c = b.getC();
D d = c.getD();
d.doSomethingUseful( y );

with

A a = registry.getSomeA( x );
a.doRealWork( y ); // a relays to its b, b to its c, and c to its d.

  (Going from the first to the second form is known as the Hide Delegate
refactoring. Notice that a.getB().getC().getD().doSomethingUseful()
wouldn't be an improvement over the first form.)

  Note I intentionally named the method on A differently, because to A's
clients another name might be much more appropriate and descriptive than
doSomethingUseful(), which in turn might be perfectly appropriate for D's
clients. But a calling sequence as seen in the first version strongly
suggests the calling code shouldn't really be a client to a D, but rather
to an A. As an added benefit, a, b, and c can all choose to decorate d's
behavior (or decline to do so) instead of simply passing the message
through 1:1. (See how the message passing mode of thinking about it can
be useful?)

  While there certainly are cases where constructs as in the first
version are ok (well, maybe not quite that extreme), in general terms I
would claim the second way is _much_ more OO. The first way forces the
calling code to have intimate knowledge of the composition not only of A,
but of B and C, as well as of D's behavior. In the second example, it
only needs to know someone who knows someone who knows someone... who
knows how to do something. Hence, better encapsulation. Of course this
can harbor its own problems, but enough rambling for now. ;-)

-- 
Cheers, Tilman

`Boy, life takes a long time to live...'      -- Steven Wright

Responding to Frebe...

>>The two most fundamental (of many) differences between OO development
>>and procedural development are the elimination of hierarchical
>>implementation dependencies
> 
> 
> This is your original claim. But later you show that it OO code may
> have hierachical dependencies too. Eliminating hierachical dependencies
> using a messaging mechanism would be possible in procedural development
> too, wouldn't it?

That's why I said the first example was terrible OO; it is procedural 
mapping of hierarchical functional decomposition onto OO.  One does 
proper OOA/D to avoid that, as indicated in the second example.

One can obviously avoid hierarchical dependencies in a procedural 3GL. 
Both Eiffel and the original C++ cfront produced C code.  One can do it 
directly if one (A) invokes only procedures that don't return values and 
(B) does not "hard-wire" the solution flow of control into the 
implementation of individual procedures (i.e., one daisy-chains flow of 
control rather than employing controller procedures to manage 
sequencing).  But that is effectively overlaying the OO paradigm onto 
procedural development (i.e., it is not how traditional SA/SD was done).

> 
> I develop message-driven applications too. This approach is useful for
> GUI logic and inter-application communication. But I can't see how it
> could be used everywhere. In your example you only show how to rewrite
> a method (ClassX::doIt) that from the start didn't return any value.
> Lets have at look at a fragment of the Date class.
> 
> class Date
>   boolean after(Date)  // Tests if this date is after the specified
> date.
>   boolean before(Date) //  Tests if this date is before the specified
> date.
> 
> Lets say I have a method myMethod in MyClass like this:
> 
> MyClass::myMethod(date1, date2)
>   if (date1.after(date2))
>     print date1
>   else
>     print date2
> 
> How can hierachical dependecies be removed using messages in this
> scenario?

This is a straw man example.  The context here is behavioral 
dependencies and sequencing behavior responsibilities.  Date is a dumb 
data holder here that has no behavior unique to the problem solution; 
'after' and 'before' are just knowledge transforms (getters).  To see 
that just rephrase:

class Date
     boolean >(Date, Date)   // overload operator

MyClass::myMethod (Date d1, Date d2)
    if (d1 > d2)
       print d1
    else
       print d2


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

H. S. Lahman wrote:
> One can obviously avoid hierarchical dependencies in a procedural
3GL.

If OO laguages can have hierachical dependencies and procedural
languages can avoid having hierachical dependencies, how can you claim
that "The two most fundamental (of many) differences between OO
development and procedural development are the elimination of
hierarchical implementation dependencies". Obviously hierachical
dependecies has nothing to do with OO or not OO.

> The context here is behavioral
> dependencies and sequencing behavior responsibilities.
Is your original claim only valid in some special contexts? Earlier you
said "Any collaborations are always peer-to-peer in any context." But
now, the context matters?

> Date is a dumb
> data holder here that has no behavior unique to the problem solution;

So hierachical dependecies is OK if a a method is hierachical dependent
on a behavior that is not unique to the problem solution? You use the
word "dumb" to avoid having to prove your claims. I think Date is a
rather complex class. Formatting dates and doing calendar operations is
not a trivial task.

> 'after' and 'before' are just knowledge transforms (getters).
I thought that a getter is a method returning a part of an object
state. I can't see how 'after' can be a getter.

> class Date
>      boolean >(Date, Date)   // overload operator
>
> MyClass::myMethod (Date d1, Date d2)
>     if (d1 > d2)
>        print d1
>     else
>        print d2
But this method still has hierachical dependecies? Are methods allowed
to return values if they can be regared as operators? Can I invent new
operators? Does not this code contain any collaboration (that "always
should be peer-to-peer")?

I can't understand how you can say that all logic implemented using
message passing or getters. When you are proven to be wrong, you just
claim the object is "dumb". I will give you two more examples. The
first example is a simplified version of java.text.MessageFormat, that
inserts strings from an array into a predefined string. How can
peer-to-peer collaboration be used between MyClass and MessageFormat?
Is MessageFormat just a "dumb" class too?

class MessageFormat
   constructor(String pattern)
   String format(Object[] arguments)

class MyClass
   void myMethod()
      format = new MessageFormat("You have entered value ? and value
?")
      read value1
      read value2
      print format.format([value1, value2])

Next example is from an enterprise context

class Employee
  String toString()

class EmployeeBroker
   Employee findByName(String name)

class MyClass
   void myMethod()
      emp = employeeBroker.findByName("ABC")
      print emp.toString()

Is 'findByName' just a knowledge method? How can hierachical
dependencies be avoided here?

Fredrik Bertilsson
http://butler.sourceforge.net

Responding to Frebe...

>>One can obviously avoid hierarchical dependencies in a procedural
> 
> 3GL.
> 
> If OO laguages can have hierachical dependencies and procedural
> languages can avoid having hierachical dependencies, how can you claim
> that "The two most fundamental (of many) differences between OO
> development and procedural development are the elimination of
> hierarchical implementation dependencies". Obviously hierachical
> dependecies has nothing to do with OO or not OO.

I can only repeat what I have said several times before: it is a matter 
of the A&D construction paradigm.  OOA/D is not SA/D.  What one can and 
can't do in a particuar 3GL is irrelevant; in fact, 3GLs in general are 
not relevant.

>>The context here is behavioral
>>dependencies and sequencing behavior responsibilities.
> 
> Is your original claim only valid in some special contexts? Earlier you
> said "Any collaborations are always peer-to-peer in any context." But
> now, the context matters?

OO collaborations are always peer-to-peer, regardless of whether 
knowledge or behavior is accessed.  However, hierarchical implementation 
dependencies are only relevant to behavior collaborations.

>>class Date
>>     boolean >(Date, Date)   // overload operator
>>
>>MyClass::myMethod (Date d1, Date d2)
>>    if (d1 > d2)
>>       print d1
>>    else
>>       print d2
> 
> But this method still has hierachical dependecies? Are methods allowed
> to return values if they can be regared as operators? Can I invent new
> operators? Does not this code contain any collaboration (that "always
> should be peer-to-peer")?

myMethod has no hierarchical dependencies because its behavior can be 
fully specified in terms of its input data and does not depend on any 
other behaviors to meet that specification.  The only dependence in the 
collaboration between MyClass and Date lies in accessing Date's knowledge.

> 
> I can't understand how you can say that all logic implemented using
> message passing or getters. When you are proven to be wrong, you just
> claim the object is "dumb". I will give you two more examples. The
> first example is a simplified version of java.text.MessageFormat, that
> inserts strings from an array into a predefined string. How can
> peer-to-peer collaboration be used between MyClass and MessageFormat?
> Is MessageFormat just a "dumb" class too?

The differences between knowledge and behavior responsibilities are 
fundamental to OOA/D.  They are defined differently (ADTs vs. methods) 
and they are accessed differently (synchronously vs. asynchronously). 
Distinguishing between them is crucial to the way the OO paradigm 
manages state variables.

> 
> class MessageFormat
>    constructor(String pattern)
>    String format(Object[] arguments)
> 
> class MyClass
>    void myMethod()
>       format = new MessageFormat("You have entered value ? and value
> ?")
>       read value1
>       read value2
>       print format.format([value1, value2])

MessageFormat transforms its data (pattern) using the provided inputs. 
So MessageFormat is, indeed, just a data holder.  It has no behaviors 
unique to the problem being solved by MyClass.

That is indicated by the fact that it is a general purpose utility that 
is reused across applications solving different problems.  Note that 
most computing space classes -- like MessageFormat, Date, and your 
collection class below -- that one finds in libraries are simple data 
holders, regardless of how complex the algorithmic content that they 
encapsulate may be.  That's because such objects are designed to be 
independent of particular problem space contexts and they are designed 
to be self-contained (i.e., they only operate on their own data).

Hierarchical dependencies only become relevant when managing the 
/solution/ behaviors that the developer creates to solve the specific 
problem in hand (i.e., the behavior responsibilities the developer 
abstracts from the problem space).  IOW, it is about how the developer 
connects the solution flow of control dots.

> 
> Next example is from an enterprise context
> 
> class Employee
>   String toString()
> 
> class EmployeeBroker
>    Employee findByName(String name)
> 
> class MyClass
>    void myMethod()
>       emp = employeeBroker.findByName("ABC")
>       print emp.toString()
> 
> Is 'findByName' just a knowledge method? How can hierachical
> dependencies be avoided here?

Of course it is a knowledge method.  EmployeeBroker is just a collection 
class; it's purpose in life to hold object references indexed by 
identity.  myMethod just asked for one.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

> What one can and
> can't do in a particuar 3GL is irrelevant; in fact, 3GLs in general
are
> not relevant.
For me 3GL are relevant, because that is the kind of languages I am
working with.

> MessageFormat transforms its data (pattern) using the provided
inputs.
> So MessageFormat is, indeed, just a data holder.
I think I disagree here. In this case, almost all classes can be
dismissed as "just a data holder".

> It has no behaviors
> unique to the problem being solved by MyClass.
Is this relevant? If the behavoir of MessageFormat would be unique for
the problem solved by MyClass, MessageFormat would not exists as an
independent class.

> That is indicated by the fact that it is a general purpose utility
that
> is reused across applications solving different problems.
The main purpose with creating a class is, that it should be reused in
different problem solutions.

> Note that
> most computing space classes -- like MessageFormat, Date, and your
> collection class below -- that one finds in libraries are simple data

> holders, regardless of how complex the algorithmic content that they
> encapsulate may be.
I think we need a definition of "simple data holder" here.

> That's because such objects are designed to be
> independent of particular problem space contexts and they are
designed
> to be self-contained (i.e., they only operate on their own data).
I would say that every class should be designed this way.

> Hierarchical dependencies only become relevant when managing the
> /solution/ behaviors that the developer creates to solve the specific

> problem in hand (i.e., the behavior responsibilities the developer
> abstracts from the problem space).
In the examples I gave you, I had to use public known problem spaces.
You try to neglect them by saying that they are not relevant in the
"specific problem in hand". But corresponding problems can be found in
any "problem space". The problem is that if I use my specific problems
in hand as examples, nobody on this forum will understand them.

> > Is 'findByName' just a knowledge method? How can hierachical
> > dependencies be avoided here?
>
> Of course it is a knowledge method.  EmployeeBroker is just a
collection
> class; it's purpose in life to hold object references indexed by
> identity.  myMethod just asked for one.

If everything can be a knowledge method (regardless how much behaivor
it takes to implements it), it is possible to have behaivor methods
that doesn't return any data.

You say: Behavoir methods should not return data, and you solve it by
qualifying every method that returns data, as a knowledge method.

Fredrik Bertilsson
http://butler.sourceforge.net

Responding to Frebe...

>>What one can and
>>can't do in a particuar 3GL is irrelevant; in fact, 3GLs in general are 
>>not relevant.
> 
> For me 3GL are relevant, because that is the kind of languages I am
> working with.

The particular 3GL used for implementation is not relevant to the 
software design.  If one does a formal OOA/D model, it does not have to 
be implemented in an OOPL but it is still an OO design.  (In fact most 
commercial OOA translation tools target C as the implementation language 
to get better performance.)

>>MessageFormat transforms its data (pattern) using the provided inputs. 
>>So MessageFormat is, indeed, just a data holder.
> 
> I think I disagree here. In this case, almost all classes can be
> dismissed as "just a data holder".

The behavior of interest is that which is unique to solving the 
particular problem in hand.  That behavior is what the developer 
"creates" by abstracting responsibilities from the problem space.  The 
developer extracts the business rules and policies of the problem space 
and connects the dots between them to form a solution.  To manage 
complexity one needs to separate those behaviors from predefined 
behaviors that have already been resolved in other problem spaces.

The Java MessageFormat facility provides a "canned" infrastructure that 
can be reused across applications solving different problems.  That 
generic implementation is not of interest to solving the problem in 
hand, which is why it is encapsulated in a reusable infrastructure so 
that it does not distract the developer from forming the real problem 
solution.  That is only possible if the rules and policies that their 
behaviors implement are based on a different problem space (e.g., 
mathematics) than the customer problem that the application is solving.

As it happens, one of the most common ways for implementing generic 
behaviors is to isolate them around data while expressing the relevant 
generic rules and policies in terms of operations on the data.  Thus 
most of the computing space artifacts like String, Array, Stack, Date, 
List, Cache, etc. are abstracted as collections of data with 
mathematically defined operations on that data.  The thing that makes 
them readily reusable is that they are self-contained; their operations 
act on only their designated data and they have no interactions with the 
problem context.

Bottom line: only the problem space entities that the developer 
abstracts in a unique fashion to solve the problem in hand will have 
behaviors that the developer needs to worry about.

>>It has no behaviors unique to the problem being solved by MyClass.
> 
> Is this relevant? If the behavoir of MessageFormat would be unique for
> the problem solved by MyClass, MessageFormat would not exists as an
> independent class.

It is very relevant to managing complexity at the design level because 
the developer must explicitly manage solution behaviors.  But if 
MessageFormat is just a data holder, it does not affect the application 
flow of control during execution.  Then the only issue the developer 
needs to explicitly address is data integrity (i.e., when "pattern" is 
assigned).

[It also has very practical implications for full code generation from 
4GL models.  If the object's methods only modify the object's own 
information, that severely limits the scope of data integrity.  However, 
that's really just a manifestation of the lower degree of coupling 
inherent in being a data holder rather than proactively interacting with 
other objects.]

>>That is indicated by the fact that it is a general purpose utility that 
>>is reused across applications solving different problems.
> 
> The main purpose with creating a class is, that it should be reused in
> different problem solutions.

Class level reuse never lived up to the hubris of the late '70s and 
early '80s.  But let's not get distracted by going there.

>>Note that
>>most computing space classes -- like MessageFormat, Date, and your
>>collection class below -- that one finds in libraries are simple data
> 
> 
>>holders, regardless of how complex the algorithmic content that they
>>encapsulate may be.
> 
> I think we need a definition of "simple data holder" here.

It's behaviors operate only on its own data; its behaviors have no 
interactions with other objects other than to acquire their knowledge; 
and it behaviors do not implement specific business rules and policies 
from the customer problem space.

>>That's because such objects are designed to be
>>independent of particular problem space contexts and they are designed 
>>to be self-contained (i.e., they only operate on their own data).
> 
> I would say that every class should be designed this way.

Most classes that abstract problem space entities send messages to other 
  objects to sequence behaviors and they often modify other object's 
data (i.e., invoke setters) in addition to operating on their own data. 
  More important, their behaviors abstract unique business rules and 
policies.

>>Hierarchical dependencies only become relevant when managing the
>>/solution/ behaviors that the developer creates to solve the specific 
>>problem in hand (i.e., the behavior responsibilities the developer
>>abstracts from the problem space).
> 
> In the examples I gave you, I had to use public known problem spaces.
> You try to neglect them by saying that they are not relevant in the
> "specific problem in hand". But corresponding problems can be found in
> any "problem space". The problem is that if I use my specific problems
> in hand as examples, nobody on this forum will understand them.

To make the software robust and maintainable in the face of volatile 
requirements one needs to ensure that there are no hierarchical 
dependencies in the business behaviors because it is those rules and 
policies that will change, not the mathematics underlying abstractions 
like an Array class.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

>> I think we need a definition of "simple data holder" here.
> It's behaviors operate only on its own data; its behaviors have no
> interactions with other objects other than to acquire their
knowledge;
> and it behaviors do not implement specific business rules and
policies
> from the customer problem space.

In that case EmployeeBroker can not be a "simple data holder" because
it is interacting with other objects for retriving an employee from the
database.

In your previous example you had a "terrible" method like this:
ClassX::doIt(x)
    tmp = x + 5;
    tmp = myClassB->doIt(tmp);
    tmp = tmp * 2;
    this->attr1 = myClassC->doIt(tmp);

But if myClassB and myClassC is just "simple data holders" and doIt is
knowledge methods, this method would not longer be "terrible", or?

> The differences between knowledge and behavior responsibilities are
> fundamental to OOA/D.
This sounds like the definition of functional programming, separation
of data and functionality.

In previous posting you say that behavoir should always be implemented
asynchronously. I think that we can agree that a "save" method is a
behavoir and not knowledge method. But what about error handling? If we
call save asynchronously, we would just proceed without knowing if the
save was sucessful or not.

Fredrik Bertilsson
http://butler.sourceforge.net

Responding to Frebe...

>>>I think we need a definition of "simple data holder" here.
>>
>>It's behaviors operate only on its own data; its behaviors have no
>>interactions with other objects other than to acquire their knowledge; 
>>and it behaviors do not implement specific business rules and policies 
>>from the customer problem space.
> 
> 
> In that case EmployeeBroker can not be a "simple data holder" because
> it is interacting with other objects for retriving an employee from the
> database.

Then it would be a rather bizarre implementation of a collection class. 
  I would expect it to maintain its own ordered array of {employee ID, 
pointer} and it would search that array to find the employee id and then 
return the relevant pointer.

What you seem to be talking about here is EmployeeBroker being some sort 
of persistence access subsystem or layer rather than an object.  If so, 
that's a different ball game.

> In your previous example you had a "terrible" method like this:
> ClassX::doIt(x)
>     tmp = x + 5;
>     tmp = myClassB->doIt(tmp);
>     tmp = tmp * 2;
>     this->attr1 = myClassC->doIt(tmp);
> 
> But if myClassB and myClassC is just "simple data holders" and doIt is
> knowledge methods, this method would not longer be "terrible", or?

That is correct.

>>The differences between knowledge and behavior responsibilities are
>>fundamental to OOA/D.
> 
> This sounds like the definition of functional programming, separation
> of data and functionality.

True; both manage state in part by separating its concerns from those of 
behavior.  But the OO and FP approaches to managing state are very 
different (e.g., the manner in which they are separated).

> In previous posting you say that behavoir should always be implemented
> asynchronously. I think that we can agree that a "save" method is a
> behavoir and not knowledge method. But what about error handling? If we
> call save asynchronously, we would just proceed without knowing if the
> save was sucessful or not.

I said that in OOA/D one employs an asynchronous model when constructing 
behaviors and <behavioral> collaborations.  However, there is nothing to 
prevent implementing the message passing synchronously during OOP if the 
problem context allows it.

To deal with the problem you describe one employs handshaking.  If we 
represent the behavior of whoever is requesting the save with a state 
machine, then the response event will be either success or failure and 
that will trigger a transition to the appropriate state and action.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

> > In that case EmployeeBroker can not be a "simple data holder"
because
> > it is interacting with other objects for retriving an employee from
the
> > database.
> Then it would be a rather bizarre implementation of a collection
class.
>   I would expect it to maintain its own ordered array of {employee
ID,
> pointer} and it would search that array to find the employee id and
then
> return the relevant pointer.

I never said it was a "collection class". That is your definition. In
my example I only had one method (findByName), but of course there
could be others like findByID, findByDepartment, etc.

Bizarre or not, but this is a common pattern used in enterprise
applications. EmployeeBroker could be a data access object (DAO) or a
facade object. In the first scenaro, it would collaborate with file
system objects, database access objects or ORM objects to retrieve
employees. Claiming this to be bizarre, you are also claiming a lot of
applications "out there" to be bizarre.

> What you seem to be talking about here is EmployeeBroker being some
sort
> of persistence access subsystem or layer rather than an object.  If
so,
> that's a different ball game.

Why? Is behaivor methods suddenly allowed to return values if they are
using other "subsystems"?? (I am afraid you will give me some fuzzy
answer about the "problem in hand" or "problem space".)

> To deal with the problem you describe one employs handshaking.  If we

> represent the behavior of whoever is requesting the save with a state

> machine, then the response event will be either success or failure
and
> that will trigger a transition to the appropriate state and action.

Lets have a simple example. We have one method that are creating a
customer order.

MyClass::createOrder(Customer customer, List products)
   try {
      order = orderTable.createRecord()
      order.setCustomerID(customer.getId())
      order.save()
      for (product in products)
          orderrow = orderrowTable.createRecord()
          orderrow.setOrderId(order.getId())
          orderrow.setProductId(product.getId())
          orderrow.save()
      transactionManager.commit()
   } catch (Exception e) {
      transactionManager.rollback()
   }

If one of the save methods fails, the entire transaction is rolledback
and no records are written. Can you show how this would be done using
asynchonous save methods?

Fredrik Bertilsson
http://butler.sourceforge.net

Andy Dent <dent@oofile.com.au> wrote in message news:<dent-E46057.21012121022005@news.highway1.com.au>...
> Umm, what has choice of syntax got to do with OOP?
> How many of the people on this thread arguing against "OOP" are arguing 
> against a particular message-oriented and awkward syntax?
> For example, a += a; could very well be implemented in C++ using 
> (horrors) OOP!
Yes, and there is exactly the problem: if you consider using OOP, you
must realize that EVERYTHING is OOP. Why make an exception for
'simple' datatypes like integers and characters? Why not let a integer
value add itself? Or a character make itself uppercase? This strange
mixture of syntax is what makes C++ a horrible OOP kludge. True object
orientation goes all the way. It's like 'I'll always love you, but not
today'.

Hans Bezemer

Responding to Frebe...

>>>In that case EmployeeBroker can not be a "simple data holder" because 
>>>it is interacting with other objects for retriving an employee from the 
>>>database.
>>
>>Then it would be a rather bizarre implementation of a collection class. 
>>  I would expect it to maintain its own ordered array of {employee ID, 
>>pointer} and it would search that array to find the employee id and then 
>>return the relevant pointer.
> 
> 
> I never said it was a "collection class". That is your definition. In
> my example I only had one method (findByName), but of course there
> could be others like findByID, findByDepartment, etc.

I assumed we were talking about a standard OO application where 
EmployeeBroker was an OOP implementation of an OOA relationship:

          1     accesses *
[Client] ---------------- [Employee]
                R1

In OOD this might be refined to:

          1                  accesses *
[Client] {Employee ID}---------------- [Employee]
                         R1

The R1 relationship would be implemented by a collection class, 
EmployeeBroker, during OOP.

> Bizarre or not, but this is a common pattern used in enterprise
> applications. EmployeeBroker could be a data access object (DAO) or a
> facade object. In the first scenaro, it would collaborate with file
> system objects, database access objects or ORM objects to retrieve
> employees. Claiming this to be bizarre, you are also claiming a lot of
> applications "out there" to be bizarre.
> 
> 
>>What you seem to be talking about here is EmployeeBroker being some sort 
>>of persistence access subsystem or layer rather than an object.  If so, 
>>that's a different ball game.
> 
> 
> Why? Is behaivor methods suddenly allowed to return values if they are
> using other "subsystems"?? (I am afraid you will give me some fuzzy
> answer about the "problem in hand" or "problem space".)

One would only get into DAO or other layered model infrastructures if 
the application objects above had to be populated from an external 
database.  The data for that initialization would be accessed in a 
separate layer or subsystem.  But DAO et al has nothing to do with the 
representation on objects within a business layer or subsystem once it 
has been populated and it executes to solve the customer's problem. 
That is very basic OO application partitioning.

[Note that DAO represents a manifestation of exactly that sort of 
application partitioning.  It is an implementation infrastructure 
expressly designed for the interface between business logic and 
persistence.  That implementation happens to be highly tailored to the 
RAD view of CRUD/USER processing in UI/DB pipeline applications.  In 
that context it is a major structural aspect.  However, for complex 
applications outside that venue it would be limited, at most, to a 
single data access subsystem.]

>>To deal with the problem you describe one employs handshaking.  If we 
>>represent the behavior of whoever is requesting the save with a state 
>>machine, then the response event will be either success or failure and 
>>that will trigger a transition to the appropriate state and action.
> 
> 
> Lets have a simple example. We have one method that are creating a
> customer order.
> 
> MyClass::createOrder(Customer customer, List products)
>    try {
>       order = orderTable.createRecord()
>       order.setCustomerID(customer.getId())
>       order.save()
>       for (product in products)
>           orderrow = orderrowTable.createRecord()
>           orderrow.setOrderId(order.getId())
>           orderrow.setProductId(product.getId())
>           orderrow.save()
>       transactionManager.commit()
>    } catch (Exception e) {
>       transactionManager.rollback()
>    }
> 
> If one of the save methods fails, the entire transaction is rolledback
> and no records are written. Can you show how this would be done using
> asynchonous save methods?

This looks like the typical VB stuff one sees in RAD pipeline 
applications.  If you honestly think this represents good OO practice 
even remotely, then I don't see any way to continue this discussion 
because we went to school on different planets.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

H. S. Lahman wrote:
> One would only get into DAO or other layered model infrastructures if

> the application objects above had to be populated from an external
> database.  The data for that initialization would be accessed in a
> separate layer or subsystem.  But DAO et al has nothing to do with
the
> representation on objects within a business layer or subsystem once
it
> has been populated and it executes to solve the customer's problem.

I don't follow you here. Should every employee be read from the
database at the startup of the application? For employees that might be
a working solution, because there are very few companies in the world
with more than a few thousands of employees. But if we were talking
about telephone calls in a telecom billing system, do you still want to
read them all into memory?

And if all data was read in the initialization, wouldn't we need
behavoir methods that returns values anyway?

> > MyClass::createOrder(Customer customer, List products)
> >    try {
> >       order = orderTable.createRecord()
> >       order.setCustomerID(customer.getId())
> >       order.save()
> >       for (product in products)
> >           orderrow = orderrowTable.createRecord()
> >           orderrow.setOrderId(order.getId())
> >           orderrow.setProductId(product.getId())
> >           orderrow.save()
> >       transactionManager.commit()
> >    } catch (Exception e) {
> >       transactionManager.rollback()
> >    }
> >
> > If one of the save methods fails, the entire transaction is
rolledback
> > and no records are written. Can you show how this would be done
using
> > asynchonous save methods?
>
> This looks like the typical VB stuff one sees in RAD pipeline
> applications.  If you honestly think this represents good OO practice

> even remotely, then I don't see any way to continue this discussion
> because we went to school on different planets.

I don't claim this to be good OO. I just want you to show how this can
be rewritten using asynchonous save methods. If you want to, you can
rewrite this to be good OO too.

Fredrik Bertilsson
http://butler.sourceforge.net

Responding to Frebe...

>>One would only get into DAO or other layered model infrastructures if 
>>the application objects above had to be populated from an external
>>database.  The data for that initialization would be accessed in a
>>separate layer or subsystem.  But DAO et al has nothing to do with the 
>>representation on objects within a business layer or subsystem once it 
>>has been populated and it executes to solve the customer's problem.
> 
> 
> I don't follow you here. Should every employee be read from the
> database at the startup of the application? For employees that might be
> a working solution, because there are very few companies in the world
> with more than a few thousands of employees. But if we were talking
> about telephone calls in a telecom billing system, do you still want to
> read them all into memory?

The application solution accesses persistence on an as-needed basis.  If 
the solution needs to process a particular Customer entity, it would 
request the data needed to initialize that entity from the persistence 
domain via an interface.  When the persistence access subsystem or layer 
returns that data, the application solution uses it to do the actual 
instantiation of the Customer object.

How the persistence access subsystem returns that data may be either 
synchronous (the solution execution is blocked until the data is 
available) or asynchronous (the solution execution can continue until 
the data is available).  The former is fine for pipeline applications 
where typically only one ad hoc UI request at a time is processed.  It 
becomes prohibitive to serialize the persistence access, though, if the 
problem being solved is complex because RDB access is on the order of 
milliseconds while solution computation is on the order of nanoseconds.

Persistence access is inherently asynchronous because of network delays, 
disk seek times, resource allocation, disk seek times, commit 
handshaking, etc.  The decision to serialize it in the persistence 
access subsystem is an OOP-level design decision.  However, the OOA/D 
model will assume an asynchronous solution because that is the most 
general case.

So in the OOA/D one sends the data request for Customer data to the 
access subsystem and the access subsystem sends another message back 
with the data when it is available.  Customer will be initialized when 
that message is received.  Usually there is no reason to change that 
even if the persistence access subsystem actually employs a serializing 
interface like a SQL driver to access the data.  Doing so would be 
bleeding cohesion across the boundary because it makes assumptions about 
the solution processing (i.e., performance won't be reduced by blocking 
the solution execution).

Providing that degree of decoupling is why subsystems in OO applications 
usually have asynchronous message-based interfaces (usually event-based) 
rather than synchronous programmatic APIs.

>>>MyClass::createOrder(Customer customer, List products)
>>>   try {
>>>      order = orderTable.createRecord()
>>>      order.setCustomerID(customer.getId())
>>>      order.save()
>>>      for (product in products)
>>>          orderrow = orderrowTable.createRecord()
>>>          orderrow.setOrderId(order.getId())
>>>          orderrow.setProductId(product.getId())
>>>          orderrow.save()
>>>      transactionManager.commit()
>>>   } catch (Exception e) {
>>>      transactionManager.rollback()
>>>   }
>>>
>>>If one of the save methods fails, the entire transaction is rolledback 
>>>and no records are written. Can you show how this would be done using 
>>>asynchonous save methods?
>>
>>This looks like the typical VB stuff one sees in RAD pipeline
>>applications.  If you honestly think this represents good OO practice 
>>even remotely, then I don't see any way to continue this discussion
>>because we went to school on different planets.
> 
> 
> I don't claim this to be good OO. I just want you to show how this can
> be rewritten using asynchonous save methods. If you want to, you can
> rewrite this to be good OO too.

If one were doing proper OO application partitioning, the concerns of 
transactionManager (DB commits and rollbacks) would be encapsulated in 
the persistence access subsystem rather than in the solution-side 
factory creating Order and LineItem instances.

The various save() operations would be one-way requests to the 
persistence access subsystem.  If there were a problem, then the 
persistence access subsystem would handle the DB side of rollbacks and 
would notify (send a message to) the solution that a problem occurred. 
The solution would then take any appropriate actions on its side for the 
failure (e.g., generate an exception).

For the sake of example, let's assume there is a OrderFactory object 
that creates Order and associated LineItem objects, given a Customer ID 
and a list of Product IDs.  That factory might have a state machine like:

         NewOder(CustID,PList)
     +-------------------------+
     |                         |
     |                         |
     V        Success          |
[Create] ----------------> [Idle]
     |                         ^
     |                         |
     | DBError(type)           | Reset()
     |                         |
     V                         |
[Error] ----------------------+

The [Create] state creates the Order and LineItem objects.  It generates 
a Save event for each Order and LineItem.  The [Error] state does 
deletion of Order and LineItem objects that it created (if necessary) 
and raises an exception.  Idle simply waits for the need to create a new 
Order.  (Idle will likely issue an event to whoever is generating the 
NewOrder event to announce that the factory is ready to accept another 
order.)

The NewOrder event triggers creating a new Order.  The Success and 
DBError events would be from the persistence access subsystem.  The 
Reset event would be from the exception handler after processing the 
exception (e.g., informing the user of the problem in the UI).

[Caveat.  There are some things I don't like about this example but I 
don't want to get sidetracked rewriting the entire application. 
Consider it simply in the context of handshaking between the problem 
solution and the persistence access subsystem.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

> How the persistence access subsystem returns that data may be either
> synchronous (the solution execution is blocked until the data is
> available) or asynchronous (the solution execution can continue until
> the data is available)

So, it is ok to have behavoir methods that returns data synchronous,
or?

> If one were doing proper OO application partitioning, the concerns of
> transactionManager (DB commits and rollbacks) would be encapsulated
in
> the persistence access subsystem rather than in the solution-side
> factory creating Order and LineItem instances.
This is impossible. The "persistence access subsystem" is not aware of
when a transaction should start or end.

> If there were a problem, then the
> persistence access subsystem would handle the DB side of rollbacks
The peresitence substystem can indeed perform the rollback, but it can
never trigger it. It is not every database call that should be followed
by a commit or rollback,

> The [Error] state does
> deletion of Order and LineItem objects that it created (if necessary)

Why not just use a rollback? Maybe because your asynchronous solution
can't handle transactions...

It would really help if you could provide some (pseduo) code examples.
I think that you don't supply examples, because your example will be a
real code bloat.

Fredrik Bertilsson
http://butler.sourceforge.net

Responding to Frebe...

>>How the persistence access subsystem returns that data may be either
>>synchronous (the solution execution is blocked until the data is
>>available) or asynchronous (the solution execution can continue until
>>the data is available)
> 
> 
> So, it is ok to have behavoir methods that returns data synchronous,
> or?

Not quite.  If all one is accessing is knowledge, then it isn't a 
behavior responsibility; it is just a getter.

>>If one were doing proper OO application partitioning, the concerns of
>>transactionManager (DB commits and rollbacks) would be encapsulated in 
>>the persistence access subsystem rather than in the solution-side
>>factory creating Order and LineItem instances.
> 
> This is impossible. The "persistence access subsystem" is not aware of
> when a transaction should start or end.

That is the /only/ place whether the notion of 'DB transaction' exits! 
Commits and rollbacks are an artifact of a particular storage paradigm 
that the problem solution should not have to understand.

You are correct that the persistence access subsystem needs to know when 
to start or end a DB transaction and, in some cases, that must be mapped 
to the problem in hand.  However, the semantics of the mapping will 
typically be quite different in the problem solution.

For example, when the user clicks the Save button in the GUI, the 
solution may send the UserWantsSave message to the storage access 
subsystem.  In the storage access domain that announcement would be 
mapped to opening a DB transaction.  When all of the relevant data has 
been provided to the storage access subsystem, then the solution may 
announce that with a DataTransferComplete message, which the storage 
access subsystem maps to commit.

If the commit fails, any rollback of the DB is strictly a matter between 
the the persistence access subsystem and the DB.  Of course the storage 
access subsystem needs to inform the solution if there was a failure. 
But what the solution does in response is no more of the access 
subsystem's business than DB rollbacks are the problem solution's business.

[Caveat.  UserWantsSave is actually a lousy semantic; I just used it 
because of the obvious UI mapping.  The real issue is that some set of 
individual interactions with persistence are logically related.  That is 
something the problem solution would know.  Then the message semantics 
would be more like StartRelatedInteractions and EndRelatedInteractions.

>>If there were a problem, then the
>>persistence access subsystem would handle the DB side of rollbacks
> 
> The peresitence substystem can indeed perform the rollback, but it can
> never trigger it. It is not every database call that should be followed
> by a commit or rollback,

True.  If one is using a serializing interface like SQL, one only needs 
commit/rollback in those contexts with multiple dependent writes (i.e., 
a DB transaction).  But the only thing the DB access subsystem needs to 
know to handle the DB transaction is that the interface requests are 
logically connected.  That is very different semantics than the 
semantics of trasaction/commit/rollback, which the persistence access 
paradigm is about.

>>The [Error] state does
>>deletion of Order and LineItem objects that it created (if necessary)
> 
> 
> Why not just use a rollback? Maybe because your asynchronous solution
> can't handle transactions...

Because if persistence is on flat files or clay tablets, there is no 
such thing as a rollback.  The problem solution should not be tied to a 
specific persistence paradigm.

> It would really help if you could provide some (pseduo) code examples.
> I think that you don't supply examples, because your example will be a
> real code bloat.

That's not the reason, though I agree the OO version would be 
significantly more verbose than your RAD example.  Consider the 
following interfaces:

class PersistenceFacade   // persistence access interface
{
public:
     startRelatedSaves ();
     endRelatedSaves ();
     saveOrder (...);
     saveLineItem (...);
}

class SolutionFacade     // problem solution interface
{
     saveSuccessful();
     relatedSaveSuccessful();
     saveUnsuccessful();
     relatedSaveUnsuccessful();
}

Note that the interface that the application solution accesses is not 
significantly more verbose that your code.  Now the persistence 
mechanisms are completely decoupled from the problem solution.  For 
example, let's say persistence is implemented with

class OrderTable
{
private:
    String tableID;
    SQLDispatcher* myDispatcher;
    SQLDataset* myDataset;
public:
    encodeTupleInDataset(...);  // invoked from saveOrder
}

OrderTable::encodeTupleInDataset (...)
{
    myDataset = new SQLDataset;
    // encode input data in data set.
    myDispatcher->setDataset (myDataset);
    myDispatcher->doWrite(tableID);
}

class SQLDispatcher
{
private:
    bool transactionOpen;
    SQLDataset* currentDataset;
    TranasctionMgr* myTansactionMgr;
public:
    openDBTransaction()
    closeDBTransaction()
    setDataset (SQLDataset* d) {currentDataset = d;}
    void doWrite(String);
}

SQLDispatcher::openTransaction()
{
    transactionOpen = TRUE;
    myTransactionMgr->newTransaction();
}

SQLDispatcher::closeDBTransaction ()
{
    if (!myTransaction->commit())
    {
        myTransaction->rollback();
        // send relatedSaveUnsuccessful() message
    }
    else
        // send relatedSaveSuccessful() message
}

SQLDispatcher::doWrite (String tableID)
{
     try
     {
        // create SQL string with tableID and dispatch currentDatasset
     }
     catch (e)
     {
         if (transactionOpen)
             mytransaction->rollback();  // will send Unsuccessful msg
         else
             // send saveUnsuccesful() message
         return
     }
     if (!transactionOpen)
         // send saveSuccessful() message
}

Now all the commits, rollbacks, and single writes are handled in the 
persistence access subsystem in a manner that is completely transparent 
to the problem solution.

[Caveat.  This could be even more generic by configuring the subsystem 
at startup using the DB schema itself.  Then the order table would just 
be an instance of Table.  That would allow the subsystem to be 
completely reusable across applications; one would just have to modify 
the interface Facade to do a table lookup for the right Table instance.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

> Commits and rollbacks are an artifact of a particular storage
paradigm
> that the problem solution should not have to understand.

You are wrong again. Transaction handling is not only related to
storage. In distributed transactions, multiple resources can
participate.  Besides databases, messsage exchage systems use to
participate in distributed transactions. Virtually any kind of resource
may participate. The problem solution really need to understand
transactions.

> Because if persistence is on flat files or clay tablets, there is no
> such thing as a rollback.

It might be. In the old days working with flat files, transaction
handling could be done, by first making a copy of the entire file. If
rollback should be done, the modified file was overwritten by the copy
file.

> the OO version would be
> significantly more verbose than your RAD example.  Consider the
> following interfaces:
Can you show me the code that corresponds to my "main" method. I am not
sure I understand your example without the full picture.

Anyway, I am very amazed to see so much similarites with your code and
Butler. Isn't SQLDispatcher a generic class that could be reused by
every application that are using a SQL database? In my example I have a
OrderTable class too, generated from the schema structure. I never
thought you could had a class that reflects the database schema. In
Butler there are a generic Table class that have the save functionality
as your SQLDispatcher, and every generated table-class subclasses this
Table class.

Fredrik Bertilsson
http://butler.sourceforge.net

Responding to Frebe...

>>Commits and rollbacks are an artifact of a particular storage paradigm 
>>that the problem solution should not have to understand.
> 
> 
> You are wrong again. Transaction handling is not only related to
> storage. In distributed transactions, multiple resources can
> participate.  Besides databases, messsage exchage systems use to
> participate in distributed transactions. Virtually any kind of resource
> may participate. The problem solution really need to understand
> transactions.

All you are citing are examples of shared data being stored externally 
to the application in hand.  Note that I said 'storage paradigm', not 
'RDB' or 'DBMS'.  Commit/rollack is just one mechanism for providing 
data integrity.  Change histories as in version control systems is 
another.  Commit/rollback happens to be ideally suited to providing 
integrity when the data is shared in a concurrent environment while 
change histores aren't.  The application shouldn't need to know what 
mechanism is actually used.

Nor does it matter whether the data maps to tables or messages; that is 
a matter of protocol at an even lower level of abstraction.

>>Because if persistence is on flat files or clay tablets, there is no
>>such thing as a rollback.
> 
> 
> It might be. In the old days working with flat files, transaction
> handling could be done, by first making a copy of the entire file. If
> rollback should be done, the modified file was overwritten by the copy
> file.

That is not commit/rollback.  There is no notion of discrete operations 
that may be individually successful but whose results cannot be accessed 
until all operations are successful.

>>the OO version would be
>>significantly more verbose than your RAD example.  Consider the
>>following interfaces:
> 
> Can you show me the code that corresponds to my "main" method. I am not
> sure I understand your example without the full picture.

Order::save()
{
     PersistenceFacade::saveOrder(...)  // attributes -> ...
}

LineItem::save(OrderID id)
{
     PersistenceFacade::saveLineItem(id, ...)  // attributes -> ...
}

Context::save()  // understands scope of saving data in problem terms
{
     OrderID id;

     id = myOrder->getID()
     PersistenceFacade::startRelatedSaves()
     myOrder->save()
     myLineItem = myOrder->getNextLineItem()
     while (myLineItem != NULL)
     {
         myLineItem->save(id);
         myLineItem = myOrder->getNextLineItem()
     }
     PersistenceFacade::endRelatedSaves()
}

Context::error()  // responds to relatedSaveUnsuccessful
{
     // does something reasonable for the problem context.
}

> 
> Anyway, I am very amazed to see so much similarites with your code and
> Butler. Isn't SQLDispatcher a generic class that could be reused by
> every application that are using a SQL database? In my example I have a
> OrderTable class too, generated from the schema structure. I never
> thought you could had a class that reflects the database schema. In
> Butler there are a generic Table class that have the save functionality
> as your SQLDispatcher, and every generated table-class subclasses this
> Table class.

That similarity should be no surprise.  As I indicated, once one has 
isolated the persistence access, it is relatively easy to recognize the 
invariants of the paradigm and then abstract them.  That allows the 
persistence access subsystem to be implemented once for a given 
persistence environment and then reused across applications.

[As I also indicated, one can do a lot better than OrderTable.  In fact, 
having an object like OrderTable impedes reuse of persistence access 
because it is application-specific.  From the perspective of persistence 
a table of orders is just an instance of Table; the semantics of 'order' 
is relegated to the value of an identity attribute.]

The problem with your solution is that it is gaining reuse at the wrong 
level.  Instead of reusing individual objects, the application should be 
reusing the entire subsystem.  Objects like SQLDispatcher and 
TransactionManager are polluting the problem solution of the particular 
application with a different paradigm that is solving a different 
problem (storage data integrity).  One has to implement a SQLDispatcher 
instance and a TransactionManager instance in every application.  Worse, 
the application solution has to be built around them because of the 
direct collaborations with them.

In my solution they are hidden behind the persistence access subsystem's 
interface and one only deals with those objects when creating the 
persistence access subsystem.  That entire subsystem -- and all the 
objects in it -- is implemented only once and shared across applications 
where SQL drivers are relevant.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Juha Laiho wrote:
> Followups set to comp.object; apologies for disturbing
comp.lang.forth
> readers, but this seems to have a sideline into that direction as
well.
>
>
> I've been trying my hand in programming Java for a while now, but
have
> failed to see the "big" difference of what is procedural and what is
OO
> programming until very recently (or this is how I currently feel).
I'm
> inviting comments on whether or not I finally have the correct idea.
My
> background is mostly from procedural languages with or without
objects
> (mostly C, perl), but I've occasionally tried to understand Smalltalk
> as well as Forth. In Java I've mostly been limited to server-side
Java
> (servlets, with an occasional touch of EJBs).
>
> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises
objects.
> Still, it would in many places be possible to write Java in more
rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.
>
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some
Java
> servlet code I've seen).
>
> The Smalltalk style appears to me to be build on very long
(Contrasting
> to Java) message chains, which begin by building some new object,
then
> doing numerous pieces of small-scale processing on that object (and
in
> the end perhaps/often returning a completely different object than
was
> originally created). I think I've seen a reference to
"message-passing
> OO" somewhere.
>
> What I often see with Java is that a single statement contains just
> a single method call - and for the cases where the method returns
> something, the return value is stored to a variable, to be used
> perhaps once or twice later on. So, in many cases, code very similar
> to the Smalltalk messaging would be possible, but is not done. This
> is the issue that seems odd to me; is this just a cultural issue
> (Java programmers largely having a strong background in procedural
> programming, and the paradigm shift is not happening), or are there
> technical issues somewhere in the history of Java?
>
> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use
of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java
code
> I've seen is just procedurally written crap - that in "real life"
(for
> some value thereof..) Java code resembles much more my representation
of
> Smalltalk?
>
> So, summarizing; what I feel is non-OO in the way I see Java code
written:
> - many methods written to return no value (void)
> - if/else constructs used instead of object polymorphism to achieve
>   differences in program behaviour
> - a lot of avoidable local variables used (references to which could
then
>   be accidentally leaked somewhere, and thus be ineligible for
garbage
>   collection)
>
> This still leaves me to think about the need of exceptions in OO
code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so
cannot
> make any comparisions on this (does Smalltalk even have exceptions?).
>
> ... and a further question: is "message-passing OO" as used in
Smalltalk
> the only form of object-oriented programming, or are there other
variants
> of "pure OO" (as in "not tainted by procedural programming")?
>
>
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data
> to the Smalltalk object-message style of programming -- just that the
> "raw" data of the Forth program is presented as objects in Smalltalk.
> Am I just seeing ghosts here, or do these two share some conceptual
> similarity?
>
>
> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on
this
> to any sensible shape.
> --
> Wolf  a.k.a.  Juha Laiho     Espoo, Finland
> (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M
V
>          PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++
y++++
> "...cancel my subscription to the resurrection!" (Jim Morrison)

From: cpu16x1...@wmconnect.com
Newsgroups: comp.lang.java.programmer
Subject: OO programming - illumination!
Date: 18 Feb 2005 19:06:38 -0800
Organization: http://groups.google.com
Lines: 70
Message-ID: <1108782398.029450.175250@c13g2000cwb.googlegroups.com>
References: <culmrd$d7e$1@ichaos.ichaos-int>
   <PcMPd.5274$u16.806@bignews6.bellsouth.net>
   <eaef3280.0502170830.b3bd93a@posting.google.com>
   <R66dnZIiVvlFeonfRVn-sw@wideopenwest.com>
   <eaef3280.0502180227.5361a645@posting.google.com>
   <1108766302.602474.22130@o13g2000cwo.googlegroups.com>
NNTP-Posting-Host: 172.209.102.108
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1108782403 29338 127.0.0.1 (19 Feb 2005
03:06:43 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sat, 19 Feb 2005 03:06:43 +0000 (UTC)
User-Agent: G2/0.2
Complaints-To: groups-abuse@google.com
Injection-Info: c13g2000cwb.googlegroups.com;
posting-host=172.209.102.108;
   posting-account=mJIrpg0AAAAp0nv7cjiDmTX72QF9L9Zf

Doug Hoffman wrote:
> Hans Bezemer wrote:
>
> > What most people seem to forget is that OO is a
> > _programming_technique_, not a "one fits all"
> > model.
>
> You might not want to lump most everyone who uses some object
> techniques into that category.  Especially in a Forth forum
> where OOP is used as an *extension* to Forth, not as a *replacement*
> for Forth.
>
>
>
> > I use OO techniques in my programs too if I want (or need) to
> > do abstraction. Yes, in C. You can easily do that. X was written
that
> > way and Axel-Tobias Schreiner wrote a whole
> > book on that subject in 1993.
> >
> > Sometimes things are not simpler than they are. This little piece
of
> > code parses a textfile. Tell me where OO helps.
>
> Make up your mind.  First you say you use OOP if you want and
> then you slam it.  ??  Give it a rest guy.  I don't think there
> is quite the amount of "hype" over OOP as you suggest.  At
> least not in Forth circles.  Why does this topic bother you?
>
> Choose your tool and program in peace.
>
> Regards,
>
> -Doug

WARNING: Failure to perform the following instructions
may lead to misunderstanding,

Maybe start simple,


Reply7471859...@wmconnect.com wrote:
>
> OO ( program development) example,
>
> Tire object,
> Road object,
> Adhesion property negotiated between Tire and Road object.
>
>
> Regards,
>
> Mark A. Washburn
>
> ---
>
> In comp.lang.forth the OT subject line should read as
>
> OO programming - illumination!
>
>
> Keep learning C/Java/Scheme, also.


Then, continue your search using the following view

http://groups.google.com/groups?q=group:comp.*+insubject:oo+insubject:programming+insubject:illumination&start=0&scoring=d&hl=en&lr=&ie=UTF-8&safe=off&num=100&as_drrb=b&as_mind=1&as_minm=1&as_miny=1981&as_maxd=31&as_maxm=12&as_maxy=2005&filter=0

Regards,

---


From: cpu16x1...@wmconnect.com
Newsgroups: comp.lang.forth
Subject: Re: Use Jesus Christ
Date: 22 Aug 2004 09:26:30 -0700
Organization: http://groups.google.com
Lines: 110
Message-ID: <d860a178.0408220826.361373fb@posting.google.com>
References: <ce0bd25d.0406160352.382f658f@posting.google.com>
<4fbeeb5a.0406201739.6a470c66@posting.google.com>
<4fbeeb5a.0406231423.696e8d3c@posting.google.com>
<ce0bd25d.0406231925.5563d0a5@posting.google.com>
<4fbeeb5a.0406241452.44122252@posting.google.com>
<d860a178.0407201505.4e5f3ea1@posting.google.com>
<d860a178.0408071702.2b20bec7@posting.google.com>
<10hb1bh6qs4krd9@news.supernews.com>
NNTP-Posting-Host: 172.133.30.84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1093191991 12037 127.0.0.1 (22 Aug 2004
16:26:31 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 22 Aug 2004 16:26:31 +0000 (UTC)

Sunday, August 22nd, 2004
8:16am

FORTH is an Object Oriented Language ( OOL)

Object Oriented Design ( OOD) is simply picturing in your mind /the
objects comprising a model of VARIABLEs, /dynamic attributes/ or
messages.

For example, VARIABLEs of a /car pavement adhesion/ problem maybe
imagined thru the objects and dynamic messages, and modeled using
VARIABLEs or meta-variables for /dynamic attribute characteristics/.

Object oriented design is a mental picture of objects and messages.

TIRE <-> ADHESION VARIABLE <-> ROAD
( NEWBIES, write a word or phrase, on a piece of blank white paper,
Then write more words or phrases. Circle words and phrases that fall
into similar groups.  Draw lines between the circled groups ( of
words/phrases).) and indicate negotiated messages, communications or
VARIABLEs shared between object groups.

( ADVANCED NEWBIES, consider building an object oriented software
model using mainly FORTH's CREATE and DOES>, ( or learning a UML
modeling tool, HDL, Scheme, or maybe consider study of the open source
Java Ptolemy II modeling environment. (
http://ptolemy.eecs.berkeley.edu/ptolemyII/index.htm )))

FORTH is bottom-up closure oriented, the meta-variables used in
originally defining an object oriented model of problem's
computability may become concrete as FORTH VARIABLE terms.

A meta-variable is a sub-problem term or a high level attribute that
is comprised of some number of definitions of sub-problems (
sub-VARIABLEs) ( however, /until/ a program IS reading and writing RAM
thru machine code, a program IS NOT using the actual VARIABLEs, maybe
only using object oriented problem mapping meta-variables.) ( a good
programming language permits the developer to design or model the
software either top-down ( non-closures) or bottom-up ( closures), as
most programming languages like FORTH, Java or Scheme do.)

CREATE, DOES>, DEFER and VARIABLE may be used for a top-down /object
oriented/ FORTH programming technique.

In this spirit/sense of /bare metal/ object oriented programming, a
genuine real de-facto VARIABLE is a /machine code object/, a fact very
well known with c.l.f community.  Yup, plain old ANSI FORTH /is/ OO
out-of-the-box, simply CREATE your objects.

For Scheme people, you may think of CAR as the execution token ( or xt
as abbreviated in ANSI language X3J14 documentation), CDR is /most
like/ >BODY , HOWEVER, many sub-definitions of >BODY are possible.
The >BODY address operation can be defined in machine code as an " >R
EXIT " sequence within an ANSI FORTH /interpreter/ for developing an
object oriented Scheme interpreter ( within ANSI FORTH), but I haven't
fully tested this.

FORTH is a real-time computable object oriented language ( with
machine level expression of VARIABLEs and an object oriented
dictionary.)

VLIW machine code continues to be strong as my best machine code level
model of Java or Scheme objects. FAULT-TOLERANT SMP MPP FORTH VLIW
uses a three-stack plus return stack model,  where two stacks extend
the basic and traditional machine code FORTH model with two indexing
stacks, X and Y.

FAULT-TOLERANT, in my usage, is a characteristic for super
super-scalability.

My dual bus architecture is somewhat flexible with internal dual-bus (
VLIW?), circuit design, HOWEVER, Level 3 fault tolerance must be fully
specified at the dual bus level, /specifically/, level three design
work is finished before non fault tolerant design.

Level 0, Non fault-tolerant.
Level 1, provides redundancy of SMP MPP processor resources, software
selected.
Level 2, uses some software for SMP MPP re-synchronization and TRUE
state recovery
level 3, Fully automatic hardware error correction
( thru redundant circuit) ( my $$$ design uses a four way redundancy,
externally signaled as RED/YELLOW/GREEN state of /any/ SMP MPP
dual-bus array processor )
( and two memory models, currently,
  1)  four SMP local memories for an Intel dynamic model and,
  2)  sixty four SMP local memories for an IBM static model. )

I guesstimated an Intel and IBM joint prototype project in 1996 at
fifty million dollars.
Today, costs may be exceeding five billion dollars.  ( Do not blame
any one of the computer chip email to Bill Gates thru
presid...@whithouse.gov)  ( BS for a computer chip. Although, maybe,
my research and design work is significantly my property, ( to publish
without any warranty whatsoever), the computer chip is not mine.   The
computer chip is mostly a simple, common and basic logic, like a
patent of the automobile /wheel/)

Your time,

your money,

you rule.

May the best chip win.  ( SMP MPP FORTH of another name brand) ( is a
/who/ product?)

Regards,

11:24am