[Oberon] Class Methods Vs. Procedure variables in Records
sinu.nayak2001 at gmail.com
Tue Jan 3 16:24:26 CET 2017
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,
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
>> Why we think, Procedure variables in Records is more elegant than
>> Class Methods?
>> Where can we find discussions/decisions on these two constructs by
> 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:
> 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:
> Chris Burrows
> CFB Software
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon