[Oberon] Class Methods Vs. Procedure variables in Records

Srinivas Nayak sinu.nayak2001 at gmail.com
Tue Jan 3 16:24:26 CET 2017


Dear Chris,

Many thanks for your insightful comments.
My good wishes for New year 2017 to you,
and all my Oberon friends.

I didn't notice "Computers and Computing - A Personal Perspective",
Niklaus Wirth, December 2015. Reading it now.

It seems, Mossenbock might have commented on this somewhere...

Let me go through "Object Oberon: An Object-Oriented Extension of Oberon."
ETH Technical Report 109, 1989, first.


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

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

On 01/03/2017 04:30 PM, Chris Burrows wrote:
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Srinivas Nayak
>> Sent: Tuesday, 3 January 2017 2:47 PM
>> To: ETH Oberon and related systems
>> Subject: [Oberon] Class Methods Vs. Procedure variables in Records
>>
>> Dear All,
>>
>> In Oberon we have Procedure variables in Records.
>> In Oberon2 we added/appreciated Class Methods.
>> But Oberon7 we only retained Procedure variables in Records.
>>
>> In the evolution of Wirthian languages, when Oberon allows object
>> oriented paradigm, why still we thought, Procedure variables in
>> Records is the way to go with Oberon7?
>> In other words, why we decided and retained Procedure variables in
>> Records, but didn't go for Class Methods? Any disadvantage of Class
>> methods?
>> Why we think, Procedure variables in Records is more elegant than
>> Class Methods?
>>
>> Where can we find discussions/decisions on these two constructs by
>> masters?
>>
>
> The two descendants of Obereon should be viewed as two siblings from the
> same parent rather than a grandparent-parent-child relationship.
>
> Oberon was designed by Niklaus Wirth.
>
> The evolution of Oberon that led to Oberon-2 was primarily the work of
> Hanspeter Mossenbock via his work with Josef Templ and Robert Griesemer on
> "Object Oberon". You can discover the motivation behind this by reading
> their paper titled "Object Oberon. An Object-Oriented Extension of Oberon."
> ETH Technical Report 109, 1989:
>
> http://e-collection.library.ethz.ch/eserv/eth:3204/eth-3204-01.pdf
>
> Oberon7, was designed by Niklaus Wirth, as an evolution of Oberon (not
> Oberon-2) in the opposite direction. It was designed to further simplify the
> language, not to extend it. His motivation is somewhat different. For an
> explanation see "Oberon, the result of simplification" in "Computers and
> Computing - A Personal Perspective", Niklaus Wirth December 2015:
>
> https://www.inf.ethz.ch/personal/wirth/Miscellaneous/index.html
>
> Regards,
> Chris Burrows
>
> CFB Software
> http://www.astrobe.com/RISC5
>
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>


More information about the Oberon mailing list