The ModulaTor logo 7KB

The ModulaTor

Oberon-2 and Modula-2 Technical Publication

The ModulaTor
Erlangen's First Independent Modula_2 Journal! Nr. 3, Apr-1994 
______________________________________________________________

 
Personal Comment on the proposals for an Object Oriented Extension of 
ISO Modula-2 

by Guenter Dotzel 

This article contains a collection of my favorite features of a simple, but powerful 
object oriented language extension (OOE) of ISO Modula-2. 

Some of the features are non-features. Object oriented programming (OOP) 
opens a new scope in programmming which allows to get rid of outdated 
features that were required in the pre-OOP area. 

I therefore propose that for compatibility reasons, all language and library 
features of ISO Modula-2 are still supported, but certain language restrictions 
shall apply in so-called class modules to allow the OOE to be as simple as 
possible. 

For a smooth migration to Oberon-2-style-OOP in ISO Modula-2/OO we would 
need the following: 

r CLASS MODULEs in addition to the traditional DEFINITION and 
IMPLEMENTATION MODULEs. 

r CLASS MODULEs "add" simplicity and safety to ISO Modula-2 by disallowing 
unsafe and unnecessary constructs (see below). 

r exported identifiers, i.e. those that are visible outside the module, are marked 
by a keyword such as EXPORT. 

r objects are simply extensible records. 

r static and dynamic objects, i.e.: records and pointer to records. 

r dereferencing with optional pointer arrow. 

r no variant records. 

r no hidden types. 

r neither nested nor dynamic (local) modules. 

r no WITH statement (considered harmful). 

r pointer base types restricted to record and array types. 

r initialisation of all pointer variables to NIL (global, stack (local), heap 
(dynamic)). 

r Oberon-2 style type test and type guard 

r no module finalisation part (with objects, you can't know whether there still 
exist objects with methods attached). 

r explicit receiver specification in type-bound procedures (methods); there is no 
need to introduce something like SELF. 

r no separation of definition and implementation in class modules. 

r type information for all non-anonymous record types in class modules to 
support persistent objects. 

Note, that the combination of interface and implementation in CLASS 
MODULEs still has definition modules, although generated automatically. The 
definition is available as soon as a skelleton module [with a possibly empty 
implementation] is written. The combination provides simple scope rules for 
objects and hence simpler compilers. Furthermore, as the experience with 
Oberon-2 shows, that without the explicit [manual] separation of definition and 
implementation, modules are easier to maintain. 

These are all provisions for a real extensible programming. More details are 
contained in [Dotz 93]. Unfortunately, this proposal was rejected, at the last 
sc22.wg13 meeting in Langley, Canada, Jun-93, because "it is not in the spirit of 
Modula-2." 

 

Other OOE-proposals [Kling 94, Henn 94] 

Do you think these proposals are in the spirit of Modula-2? 

I'm critisizing, that the inherent complexity involved with the scope concept and 
semantics of a class declaration which may partially be contained in the 
definition and implementation modules can be avoided by taking the Oberon-2 
approach which combines both modules. This would not only simplify the 
language, but also the compilers (as proven with the Oberon-2 compilers). 

We don't need class modules within modules, with an artificial scope concept. In 
[Henn 94] class modules are records, but look like modules. Import, exports and 
inheritance within a record scope is possible. 

There is no need for classes in addition to [extensible] record types. It's an 
avoidable new concept. 

In class modules, records are objects and records are extensible. Of course, 
one can still have a pointer to a record. Nothing new. [Henn 94] introduced other 
new concepts: value based and pointer based objects, the latter being the 
default object. Needless to say that this is not necessary. 

Further critique on [Henn 94]: What is inside a local class module and what is 
outside? What procedures are bound to a type and what not? There is no 
explicit receiver. Because the access is not explicitly using the name of the 
receiver (there ain't no name), it is not obvious where record fields (attributes) of 
the receiver is accessed. 

 

What happens when? 

If the critique expressed above is not accepted, I bet that the ISO 10154 
Working Group sc22.wg13 story will go like the following: 

Some proposals are already made for the Apr-1994 meeting, then they are all 
re-designed for the next meeting(s). When a proposal finally gets drafted, after 
the VDM-SL was written, the OO extension will be withdrawn at a meeting, 
maybe in 1997. In the meantime, programmers seriously interested in OOP 
already switched to [being optimistic] Oberon-2. ISO Modula-2 papers will show 
up only at the HOPL (history of programming languages) conferences. From 
1994, nobody is talking about ISO Modula-2 because it doesn't support 
extensible programming and not even OOP. 

Keep the "spirit and tradition" of Modula-2 by designing an OOE of ISO 
Modula-2, which is simpler than ISO Modula-2 itself. Otherwise you'll not see a 
ISO Modula-2 Compiler implementation with OOE before the end of this 
century. 

As long as we have ISO Modula-2 without OOE I'm committed to the Standard. 
A soon as we want something like ISO Modula-2/OO we have to get rid of many 
features currently in ISO Modula-2 which are only there for historical reasons. 
Of course upward-compatibility must be guaranteed to not invalidate most of the 
existing PIM-style Modula-2 programs. But we need to provide this guarantee 
only as long as no OOP features are used. 

 

Conclusion 

If ISO Modula-2/OO isn't as simple as Oberon-2, which can be qualified 
essentially by 

- an object is an extensible record, 

- pointer safety, 

- polymorphism, 

- run-time type information and persistent object support via library, 

ModulaWare's Modula-2 compilers are frozen to the current language/library 
level of ISO Modula-2 (minus Exceptions). 

When it comes to OOP we'll go for Oberon-2, where extensibility is needed (and 
you never know in advance) and when working on large software projects 
(which are more easily maintained, because there are no definition modules). 

In general, a language must be designed so that errors are avoided from the 
beginning by having proper syntax. Such a design is not easy and needs a lot of 
experience and finger-tip fealing. My opinion still is that an OOE of ISO M2 
which would be accepted later by a significant number of programmers, can't be 
done by a standardisation committee in reasonable time unless the simplest 
possible way is choosen, based on hands-on experience. 

I always refuse to think about complicated things. This is one of the reasons why 
I've choosen Modula-2 in 1981, when I needed a simple, modular, real-time, 
structured language. 

Isn't that the spirit and the tradition of Modula-2. Only the simplest tools allow 
the construction of complex software. 

 

References 

[Dotz 93] Guenter Dotzel: How to turn a great separation into a better 
partnership. or A modest proposal for an object oriented extension of ISO 
Modula-2. In The ModulaTor [3, 4] May-93 

[Kling 94] Markus Klingspor; Juergen Wolff von Gudenberg: Modula-2O - An 
object oriented extension of Modula-2. Dedicated to Professor N. Wirth on the 
occasion of his 60th birthday. In The ModulaTor [4, 1] Feb-94 

[Henn 94] Elmar Henne; Albert Wiedemann: Proposal for Object Oriented 
Extension of [ISO] Modula-2. In The ModulaTor [4, 2] Mar-94 
________________________________________________________________
 

Editorial 

The ModulaTor is an independent TechJournal which covers technical articles 
about Modula-2 and Oberon-2 and its descendants. As the Editor of the 
ModulaTor it is my responsibility to provide our readers with a well balanced 
selection of articles. I've decided to publish the above mentioned proposals 
[Henn 94, Kling 94], although I don't like either. I've already expressed my 
concerns to all working group members on the sc22.wg13 Email list recently. 

Attention: If you don't like any of the published OO-extension proposals, please 
contact the authors or better write a letter or fax to the head of your national 
body of ISO 10154 working group sc22.wg13 and tell about your concerns now. 
Since the German subgroup is responsible for the OOE of ISO Modula-2, best 
would be to contact the DIN representant of the German Modula-2 working 
group NI-22.13 directly: 

Mr. Wolfgang Redtenbacher, Benzstr. 4, D - 7253 Renningen, fax: +49 (07159) 
17047 

Please don't delay: The next meetings of sc22.wg13 are in early Apr-94 in New 
Zealand and in the fall '94 in Vienna, Austria. If you don't complain now, it is 
possible that parts of the actual proposals are taken over to the final OOE of ISO 
Modula-2. 
________________________________________________________________
  

The Forum 

In 18-Feb-1994, a UK-based Modula-2/Oberon-2 compiler distributor 
announced that there is something like an internationally agreed definition of 
Oberon-2 language known as 'Oakwood' standard which has recently been 
endorsed by ETH[-Zuerich]. 

All I can say about this announcement is that nothing was agreed, and surely 
not internationally. Instead the proposed standard got criticised by many 
Oberon implementors (including Hartmut Goebel, Dieter Jaeger and me; also I 
know of other Oberon implementors who don't care about 'Oakwood'). I'm tired 
in fighting against such announcements which I regard as unfair business 
practices. 

Regards, Guenter Dotzel 

PS.: For those who are interested, a copy of the 'Oakwood' proposal (which 
contains many language extensions) is available for download at 
http://www.xds.ru 

________________________________________________________________

IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached by tel/fax: [removed due to abuse] or by mailto:[email deleted due to spam]
  ModulaWare home page   The ModulaTor download    [Any browser]

Webdesign by www.otolo.com/webworx, 14-Jul-1998