[Oberon] Class Methods Vs. Procedure variables in Records

Fri Mar 3 11:40:00 CET 2017

That is exactly right: There are indeed no type extensions in the Oberon "inner core" (modules Kernel, FileDir, Files and Modules). And almost no type extensions in the "outer core" (modules Input, Display, Viewers, Fonts, Texts, Oberon). The one exception I found is in module Texts (type Scanner is an extension of Reader - which we could certainly get rid of if we just wanted to) and -  of course - the types related to the viewer system in the two modules Viewers and Oberon. This leaves us with the two modules that complement the viewer system (modules TextFrames and MenuViewers) where type extensions are - and should be - used.

Now that you have made me think about it again... One can in fact view the argument that was made in favor of the "instance-centered" view in yet another way: The moment one decides to provide class mechanisms as a language construct, people *will* use them indiscriminately - even in the (many) cases when one should, in fact, better not make use of them. Witness today's main mobile platforms for example, where it is in fact practically impossible *not* to use classes..

So the very *absence* of class mechanisms in Original Oberon is supposed to provide just the right amount of "negative incentive".

Andreas

Sent from my iPhone

> On 3 Mar 2017, at 10:34, Srinivas Nayak <sinu.nayak2001 at gmail.com> wrote:
> 
> Nice explanation Andreas.
> Many thanks for your valuable time and information.
> 
> New learning for me is that, except Viewer system, "type extension" is even not used in rest parts of Oberon.
> 
> To my knowledge, this fact is also seen from Unix; plainly in C, without any OO style.
> Only in Graphics related stuff we need OO style...
> 
> 
>> On Fri, Mar 3, 2017 at 12:15 PM, Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
>> Srinivas,
>> 
>> 1. By "conventional programming style" I mean using the Oberon language, but without using *OOP concepts* such as installed handler procedures in extensible records or extensible message records passed as VAR parameters to handler procedures. The observation made was that in the Oberon system such techniques are used *only* in the viewer system. With respect to your comment about the Oberon-2 programming language, note that the Oberon operating system is written entirely in the (original) Oberon language, with no parts written in Object Oberon or Oberon-2. So the argument was mostly about using "the OOP concepts" rather than being specific about the language used. The point made by the defendants of the "instance-centered view" (Original Oberon camp) was that the feature of "type extensions" is really all that you need, given that in the Oberon system, *OOP concepts* are used only in the viewer system. And for *that*, type extensions, as provided in the original Oberon language, have been proven to be amply sufficient. It is therefore does not seem to be necessary to also add *additional* features such as the CLASS construct (as introduced in Object Oberon) or type-bound procedures (as introduced in Oberon-2). Such additional language constructs would only have been justified if there had been *other* areas (i.e. outside the viewer system) where type extensions *alone* are not enough. The one area that one could possibly think of were graphics editors. Why? Because there, you may have hundreds or even thousands of graphics elements (such as lines, circles, ellipses, entire drawings, etc) as opposed to (typically) only half a dozen simultaneously open viewers, as in the Oberon viewer system. Thus, the need for efficient upcalls *might* in fact have been a good argument in favor of the "class-centered" view (which does offer more efficient upcalls via class methods) - at least on machines available in the early 1990s. However, the "Draw" editor has shown, that you *can* in fact eliminate also the often cited performance disadvantage of message handlers (with their cascaded IF statements that needed to be executed at run time) by effectively programming "by hand" what Object Oberon and Oberon-2 achieve with a language construct. Namely a single method "do" that is installed in each instance, which simply points to a method table programmed "by hand". This of course comes at the expense of a rather verbose way of programming relative to Object Oberon or Oberon-2 - just study the module Graphics.Mod to see why.
>> 
>> 2. Regarding the use of *OOP concepts* in the Oberon compiler itself, the point was that one does not only NOT need the additional features provided by Object Oberon or Oberon-2, such as the CLASS concept (Object Oberon) or type-bound procedures (Oberon-2), but that even the Original Oberon concept of *type extensions* is NOT needed. Nothing. No type extension, no classes, no type-bound procedures. And indeed, the four modules ORS, ORB, ORG and ORP don't contain any type extensions or installed handler procedures. In other words, the Oberon compiler is (practically) written in Modula-2, and for good reasons. In fact, I learned compiler writing in Modula-2 on MC68000 years before Oberon was created. Then, when Oberon came along, the transition was trivial (as far as the language constructs used in the compiler itself were concerned).
>> 
>> Andreas
>> 
>> 
>> From: Srinivas Nayak <sinu.nayak2001 at gmail.com>
>> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch> 
>> Cc: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
>> Sent: Friday, March 3, 2017 6:36 AM
>> Subject: Re: [Oberon] Class Methods Vs. Procedure variables in Records
>> 
>> Dear Andreas,
>> 
>> From your post...
>> "Look, an entire operating system (the Oberon system) could be advantageously written in the conventional programming style. So this fact alone impressively proves that OOP is not all that essential, even when writing an entire OS. The only exception is the viewer system - which however is done now."
>> 
>> If I understood correctly,
>> do you mean,
>> "Look, an entire operating system (the Oberon system) could be advantageously written in the conventional programming style *(with only one extra thing, "type extension"; i.e extending a record)* . So this fact alone impressively proves that OOP is not all that essential, even when writing an entire OS. The only exception is the viewer system - which however is done now. *(which uses "type extension"; i.e extending a record)* "
>> 
>> And in case of compilers, they said, "type extension" is also not a need, since one needs bootstrapping anyway... and that is why, Oberon even doesn't use type extension feature when it is bootstrapped using a subset of Oberon, i.e. Oberon-0.
>> 
>> Is my understanding correct?
>> 
>> 
>> On Wed, Mar 1, 2017 at 12:36 PM, Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
>> Richard Hable Tue Feb 28 20:23:00 CET 2017
>> > > Wirth remains: these languages are still too complex. Why again are
>> > > there separate concepts for structs (=records), classes (=pointers to
>> > > records), modules, and protocols, and extensions, and and .. in Swift,
>> > > when exactly two would do (records for data structuring and modules for
>> > > information hiding)?
>> >
>> > On the other hand, if you use Oberon or Oberon-2, you need at least
>> > three definitions in order to define a simple class: the module
>> > containing the class, a record type containing its member variables, and
>> > a pointer type referring to the record.
>> >
>> > Richard,
>> 
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> 
>> . . . which this is why I wrote in my original post of January 3rd, 2017:
>> 
>> > 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.
>> 
>> You are right, one does indeed need module, record and pointer declarations to implement the OOP style exemplified in the Draw editor that is part of the Original Oberon distribution.
>> 
>> On the other hand: Apart from the viewer system and a handful of document editors like Draw, one *could* make the argument that there is not much need for using OOP in many other places. One may of course agree or disagree with that statement -personally, I have no predisposition one way or the other. But as I stated in my original note from Jan 3, 2017, this was (more or less) the essence of the main argument brought forward by the "instance-centered" group at ETH around Prof. Wirth (the "Original Oberon” camp so to speak) in the early 1990 - I was just reporting what has been said back then during the debate. They basically argued: "Look, an entire operating system (the Oberon system) could be advantageously written in the conventional programming style. So this fact alone impressively proves that OOP is not all that essential, even when writing an entire OS. The only exception is the viewer system - which however is done now." This argument, when it is thrown at you, is hard to argue agains, given that the authors of the Oberon system have gone to great lengths of actually implementing it :-) So their argument felt a little bit like this: "Guys, we already did it (once) in the Oberon viewer system, so no need to do it again there. Of course, 'you app developers' out there can use OOP it in a things like document editors where you can use Draw as a template. Just copy it and you’ll see, you’ll fine. It’s all you need. But: this is it! Document editors and, perhaps, a few other scenarios. Where else would you 'really' need OOP?". Indeed, there is only a handful of document editors, not thousands, that have been developed over the years.
>> 
>> But of course, despite this rather purist few, people at ETH back then have written other software using the OOP style using either Object Oberon or Oberon-2 — after all, one has to master it, right?. I have used both Object Oberon and Oberon-2 extensively. At one point, even the Oberon-2 compiler itself was reexpressed in Oberon-2, using type extensions and type-bound procedures to distinguish between the different kind of entries in the compiler's list of the declared symbols (the so-called symbol table) for example. Of course [..note: when you were at ETH in those days, one develops a kind of Pavlov effect, in the sense that one already knows what the answer is going to be before it is even given..], the "counter argument" against THAT decision was to state the following: (i) look, a compiler is typically bootstrapped, i.e. it *must* first be written in another language that does not support type extension, such as Modula-2. So in any case, you have to start with a compiler that (almost by definition) cannot possibly use type extension (because it's the feature you are actually implementing for the first time), (ii) not using type extensions makes it easier to translate the compiler into *other* languages, a step that may be necessary in yet another bootstrapping exercise on yet another platform where Oberon-2 is not yet available, and (iii) why again would you use type extensions in a program such as a compiler in the first place when *all* extensions are already known at the time the compiler is written, i.e. the compiler will - by definition - not ever be extended in any substantial way in the future (unless the language itself is changed of course in a substantial way, which however has not happened in the last 25+ years last time I checked). In this particular example, my personal view is that using Oberon-2 does indeed increase the readability of the compiler somewhat - mainly because one no longer has to remember what  all those multi-purpose fields for class-specific attributes actually mean. But that is not a particularly strong argument, considering that the entire compiler is now down to only about 2500 lines. You either master THAT or you don't. If you don't, no amount of rewriting it in a a slightly more convenient notation will make you understand it better..
>> 
>> But there are other examples of programs that have been built using Oberon-2. But again, that Pavlov reflex..
>> 
>> Of course, from an educational point of view, it is perhaps indeed asked too much from eg a 16-year old to reconstruct a Draw-like system from scratch. They just won't. And this is why I added my *personal* remark (re-inserted above) which states that the additional elements (class keyword, type-bound procedures, etc) *may* make some sense from a practical point of view - even though the purist may claim they are not really needed.
>> 
>> But we don't live in a purely academic world of course!. Imagine an Android or iOS development environment (IDE) with only Oberon or Oberon-2, but no class concept as provided by Java (on Android) or Objective-C/Swift (on iOS). It would not be as easy for many programmers. Many would be lost indeed. I don't see how the platform providers could have achieved the degree of uniformity that they have without certain "templates" pre-canned (and pre-built into) the IDE. All Android and iOS apps look alike (from a principal point of view only of course). The same can certainly *not* be said of Oberon-(1,2).
>> 
>> Andreas
>> 
>> 
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/ mailman/listinfo/oberon
>> 
>> 
>> 
>> 
>> -- 
>> With thanks and best regards,
>>  
>> Yours sincerely,
>> Srinivas Nayak
>>  
>> Home: http://www.mathmeth.com/sn/
>> Blog: http://srinivas-nayak.blogspot.in/
>>  
>> 
>> 
> 
> 
> 
> -- 
> With thanks and best regards,
>  
> Yours sincerely,
> Srinivas Nayak
>  
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170303/89d970d9/attachment-0001.html>