[Oberon] objects and jewels

[Jörg]

Frans-Pieter

> I remember reading an argument of Wirth against object orientation.
However
> the object way, "myservo.atttach(9)" seems more elegant than the modular
> way. Did I overlook something?

You might consider this syntax as more elegant, but basically
object-oriented programming (OOP) does not add one single new concept to
traditional procedural programming (PP). Read Wirth's argumentation below.

Whether you write in OOP "myservo.attach(9)" or write in PP
"SERVO.Attach(myservo, 9)" is the same.

br
Jörg

Wirth:
    “Many people tend to look at programming styles and languages like
religions: if you belong to one, you cannot belong to others. But this
analogy is another fallacy. It is maintained for commercial reasons only.
Object-oriented programming (OOP) solidly rests on the principles and
concepts of traditional procedural programming (PP). OOP has not added a
single novel concept, but it emphasizes two concepts much more strongly that
was done with procedural programming. The fist such concept is that of the
procedure bound to a composite variable called object. (The binding of the
procedure is the justification for it being called a method). The means for
this binding is the procedure variable (or record field), available in
languages since the mid 1970s. The second concept is that of constructing a
new data type (called subclass) by extending a given type (the superclass).

    It is worthwhile to note that along with the OOP paradigm came an
entirely new terminology with the purpose of mystifying the roots of OOP.
Thus, whereas you used to be able to activate a procedure by calling it, one
now sends a message to the method. A new type is no longer built by
extending a given type, but by defining a subclass which inherits its
superclass. An interesting phenomenon is that many people learned for the
first time about the important notions of data type, of encapsulation, and
(perhaps) of information hiding when introduced to OOP. This alone would
have made the introduction to OOP worthwhile, even if one didn’t actually
make use of its essence later on.

    Nevertheless, I consider OOP as an aspect of programming in the large;
that is, as an aspect that logically follows programming in the small and
requires sound knowledge of procedural programming. Static modularization is
the first step towards OOP. It is much easier to understand and master than
full OOP, it’s sufficient in most cases for writing good software, and is
sadly neglected in most common languages (with the exception of Ada).

    In a way, OOP falls short of its promises. Our ultimate goal is
extensible programming (EP). By this, we mean the construction of
hierarchies of modules, each module adding new functionality to the system.
EP implies that the addition of a module is possible without any change in
the existing modules. They need not even be recompiled. New modules not only
add new procedures, but – more importantly – also new (extended) data types.
We have demonstrated the practicality and economy of this approach with the
design of the Oberon System.”

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4939 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20130219/98335064/attachment.bin