[Oberon] objects and jewels

[Frans-Pieter Vonck]

Dear Felix,

thank you for the explanation. Missed this in the literature.
With the assignment aLed.init := init things are clear.
> An attempt to call a non-initialized procedure variable usually results
> in a trap.
I'm curious, do you think this an code error that should be discovered by
the compiler in stead of generating a trap at runtime?

Greets,

F.P.



> Dear Frans-Pieter,
>
> procedure types are types such as INTEGER or REAL. If a variable is of
> procedure type T, then it means that it is capable of holding a pointer
> to executable code of a procedure that has the interface desribed by T.
> It is actually not more and not less. (It is slightly different in
> ActiveOberon with Delegates -- different story.)
>
> This means that a variable, field or parameter of procedure type is not
> automatically bound to executable code, but the binding has to be
> provided by "the user". In your example, this could have been done via
> an assignment aLed.init := init
>
> An attempt to call a non-initialized procedure variable usually results
> in a trap.
>
> Regards
> Felix
>
>> 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."
>>>
>>>
>>
>>
>>
>>
>>
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>