[Oberon] objects and jewels

[Frans-Pieter Vonck]

Thanks Jorg,
this was the interview I remembered. However the interview mentions
extention of record types, but not the introduction of procedure types.

I could not find simple examples of using procedure types, probably
because of the introduction of type bound procedures with Oberon-2.

The original oberon system uses procedure types a lot as part of the
message concept. I wonder if the concept of message handling together with
the task loop can be transfered to microcontrollers.
Procedure Types are supported in Oberon07.

To start simple, I was thinking of something like this
MODULE ExampleProcType;

TYPE
 Led = RECORD
         pin, port : INTEGER;
         init : PROCEDURE(led : Led; Pin,Port:INTEGER)
        END;
VAR aLed : Led;

PROCEDURE init (led: Led; Pin,Port: INTEGER);
(*some code *)
END init;

BEGIN
  aLed.init(aLed,1,5)
END ExampleProcType.

This compiles in Astrobe. But i do not know what is happening here. For
instance, if I change the name of the PROCEDURE init to PROCEDURE onit the
module still compiles. So it seems that the procedure type init not binds
with the procedure init.

Could someone explain me a little more about procedure types?

Greets,

Frans-Pieter

> 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.”
>
>