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

[Srinivas Nayak]

Dear All,

I am an animal from C world. Forgive me. :-)
However, I heartily respect Oberon and simplicity.

One thing I couldn't understand, what was the need of pointers?
Is it really needed for a programmers to know and differentiate, "this 
is a pointer" and "that is a plain variable", and now we have "two 
different ways to access the same thing"!

If pointer is important from faster execution point of view, can't 
languages keep this implementation things hidden from programmers? In 
the same way as "procedure variables" hide the concept of "function 
pointers".


I was very much surprised, when I saw this nasty thing present in 
Oberon. Never expected!

With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/


Frans-Pieter Vonck wrote:
> 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.”
>>>
>>>
>>
>>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>