OO programming - illumination?

OO programming - illumination?

Post by Peter van » Mon, 14 Feb 2005 08:24:43

uha Laiho wrote:


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

[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



> This'd explain my perplexion in not seeing that much

OO programming - illumination?

Post by BR » Mon, 14 Feb 2005 11:24:20

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