<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1483438860077_9540"><span></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1483438860077_9503" dir="ltr"><pre id="yui_3_16_0_ym19_1_1483438860077_9650">This topic has been the subject of intense debate at the Institute of Computer Science at ETH Zurich around 1988-early 1990s. It's hard to convey the full spirit of these discussions so many years later, but I'll try to summarize some of the key aspects that were discussed back then, at least as far as object-oriented programming is concerned. One key topic was of course whether the language should be "instance-centered" vs. "class-centered".</pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650"><br></pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650">First, a language called Object Oberon was devised and implemented at ETH Zurich. It was essentially a class-centered derivative of the original Oberon language (adding a keyword CLASS and class methods, etc). I have used it extensively. Among other things, that project demonstrated that adding a class mechanism to an existing language can be achieved with relatively little extra effort. And indeed, the compiler's complexity increased only moderately (10-20%). Then Oberon-2 was devised, which essentially removed the CLASS keyword and added type-bound procedures instead, i.e. classes where now again also called what they really are - namely records. It too was not significantly more complex than the original Oberon language and compiler. Of course much simpler than the OOP languages that emerged during that period (we were still in a pre-Java world back then and had to put up with C++ or the like).</pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650"><br></pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650">But even though it was demonstrated that the additional complexity of the compilers for Object Oberon and Oberon-2 remained within tolerable bounds, the debate was not about that, but rather whether the notational conveniences justify the conceptual complications.</pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650"><br></pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650">The "defendants" of the original Oberon language (instance-centered with procedure variables) argued that while it is true that class-centered languages (with class methods, a.k.a. type-bound procedures) offer a somewhat more convenient notation, increased security, and also more efficient upcalls, this was considered a marginal advantage. It was believed the object-oriented programming style should be confined to a few select cases only, i.e. one should use it only where it is justified and deemed appropriate - whatever that means (seen from today's point of view, where Java has achieved such a dominant position, and where it seems that almost everything has to be a class, this may sound strange, but back then the OOP style has not yet gained widespread adoption and many ideas were still in flux). The "case study" cited as proof was of course the Oberon System itself: It showed that the entire Oberon system could be programmed in conventional programming style, except for one area: the viewer system, as everyone knows who contributed to or extended the viewer system.</pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650"><br></pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650">It was a lively debate, to say the least.. But in the end, the question remained open. This is, I believe, one of the reasons why we now have two main version of the Oberon language: Oberon and Oberon-2.</pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650"><br></pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650">Personally, I believe Oberon7 is enough for many purposes, and that certainly includes system design. And that is why I decided to stick to the original Oberon language in Experimental Oberon. But that is entirely my personal bias. From an educational point of view, I would consider using Oberon-2 instead, as it very nicely and cleanly demonstrated the various OOP concepts. But in any case, more important than the choice of the language is, I believe, to teach the debate.</pre><pre id="yui_3_16_0_ym19_1_1483438860077_9650"><br></pre><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1483438860077_9509" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1483438860077_9508"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1483438860077_9507"> <div dir="ltr" id="yui_3_16_0_ym19_1_1483438860077_9506"> <font size="2" face="Arial" id="yui_3_16_0_ym19_1_1483438860077_9505"> <hr size="1" id="yui_3_16_0_ym19_1_1483438860077_9504"> </font></div><div class="y_msg_container" id="yui_3_16_0_ym19_1_1483438860077_9510"><div id="yiv8252511053"><div id="yui_3_16_0_ym19_1_1483438860077_9512"><div style="color:#000;background-color:#fff;font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px;" id="yui_3_16_0_ym19_1_1483438860077_9511"><h1 style="font-family:-webkit-standard;" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5970"><span style="font-family:'Courier New';white-space:pre-wrap;font-size:13px;font-weight:400;" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_6029">Srinivas Nayak sinu.nayak2001 at gmail.com </span></h1><h1 style="font-family:-webkit-standard;" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5970"><span style="font-family:'Courier New';white-space:pre-wrap;font-size:13px;font-weight:400;" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_6030">Tue Jan 3 05:17:06 CET 2017</span></h1><pre id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5989"><pre id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_6016">All,</pre>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?
Kindly note that, in this query,
my focus is on Language design, rather than Language use.
With thanks and best regards,
Yours sincerely,
Srinivas Nayak
Home: <a rel="nofollow" target="_blank" href="http://www.mathmeth.com/sn/" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5990">http://www.mathmeth.com/sn/</a>
Blog: <a rel="nofollow" target="_blank" href="http://srinivas-nayak.blogspot.in/" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5991">http://srinivas-nayak.blogspot.in/</a>
</pre><div dir="ltr" id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5992"><br id="yiv8252511053yui_3_16_0_ym19_1_1483438860077_5993"></div></div></div></div><br><br></div> </div> </div> </div></div></body></html>