Abstract classes in Oberon / OOC

[Stewart Greenhill <greenhil@murdoch.edu.au>]

Hello,

One of the serious problems with Oberon-2 (in my opinion) is that it lacks
support for abstract classes. Abstract classes specify frameworks for
classes - they contain definitions for abstract methods which must be
implemented by sub-classes. In OOC, module Channel.Reader is an example.

The convention in Oberon systems seems to be to treat abstract classes as
concrete (non-abstract), and to raise an exception at run-time if an
abstract method is called. In terms of safety, this is a complete disaster!
It is WAY too late to learn at run-time that you have forgotten to
implement an abstract method. This is a great source for potential errors
that may only rarely be manifest.

To correct these problems, the programmer should be able to specify whether
a class is abstract or not. The compiler should NEVER allow abstract
classes to be instantiated. If a derived class is not abstract, an error
should be generated if there are abstract methods that have not been
implemented.

Component Pascal introduced the ABSTRACT keyword for method and class
declarations. If a method is tagged ABSTRACT, it is allowed to be
unimplemented (ie. no procedure body is specified). If a class is tagged
ABSTRACT, it is allowed to have abstract methods. An abstract class can
never be instantiated. There are a couple of subtleties that aren't
implemented properly, but on the whole Component Pascal gives a BIG safety
improvement in this respect.

Would it be possible to add something like this to OOC? Here are two
possibilities:

1) Allow [ABSTRACT] tags to be used on RECORD and PROCEDURE declarations.
For ABSTRACT procedures the body is ignored if specified.
-- OR --
2) Interpret a procedure with a single HALT(abstractMethod) statement as an
abstract method.

Neither of these options requires a change to the syntax of the language.
They do allow the programmer to better inform to the compiler about what is
intended, and for the compiler to check that no unintended mistakes are
made. Approach (2) has the disadvantage of only allowing abstract methods
to be declared, not abstract classes. For the compiler to properly check
that you have implemented all abstract methods, it needs to know whether
you intend to declare an abstract or concrete class. Therefore, (1) is my
preferred approach.

Comments? Language purists: please don't flame me too hard :-)

- Stewart