[Oberon] [Fwd: RE: objects and jewels]

[Frans-Pieter Vonck]

thanks Jörg for your hint to the instantiation init
aLed.init := Init; I missed that.

> Remark: I would only pass a Led pointer to the procedure Init (either by
> declaring Led as POINTER or declaring led as VAR parameter) but this has
> nothing to do with the asked topic "procedure variables".
Yes yo'ure right,
I try out how it works out when I create a driver MODULE LED that is
imported by BlinkaLed.

Greets,
Frans-Pieter





> Hi FP
>
> Your example code could look 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);
>     BEGIN
>       (*some code *)
>     END Init;
>
>   BEGIN
>     aLed.init := Init;
>     aLed.init(aLed, 1, 5);
>   END ExampleProcType.
>
>
> Remark: I would only pass a Led pointer to the procedure Init (either by
> declaring Led as POINTER or declaring led as VAR parameter) but this has
> nothing to do with the asked topic "procedure variables".
>
> Jörg
>
> -----Original Message-----
> From: Frans-Pieter Vonck [mailto:fp at vonck.nl]
> Sent: Dienstag, 19. Februar 2013 16:47
> To: Jörg
> Subject: RE: [Oberon] objects and jewels
>
> 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.”
>>
>>
>
>
>