Re: Possible changes to abstract types proposal

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

>> (Q2) Should it be possible to declare abstract extensions of concrete
types?
>
>Earlier Stewart Greenhill wrote:
>> Personally, I don't favour re-abstraction of concrete types because it
>> encourages implementation inheritance which often leads to trouble (eg. the
>> semantic fragile base class problem). Component Pascal (after which I
>> modelled this proposal) does not allow abstraction of concrete types.
>> However, I acknowledge that there are valid uses for this construct and
>> that it is probably more a matter of programming style than technically
>> necesssary. I would never use it, but I'm prepared to relax point (3) in
>> the original proposal to allow this.
>What is the semantic fragile base class problem? I can't remember a
description
>of this problem.

The fragile base class (FBC) problem considers whether a base class can
evolve without breaking independently developed sub-classes. The semantic
FBC problem is: how can a subclass remain valid when the implementation of
its superclass has changed? If subclasses rely excessively on the
implementation of their parent classes, the two cannot evolve
independently. This was the point I was making about re-abstraction. If you
seek to make a concrete type abstract, it is probably because you want to
re-use part of its implementation. There are other ways of doing this which
don't rely on inheritance (eg. object composition).

>If the answer was no a programmer could avoid abstract classes at all.
>I would say yes, too.
>
>
>This extension is modelled after Component Pascal, why introduce only
>one feature? Why not changing OOC into a Component Pascal Compiler?

I'm sure that there are many Component Pascal developers who would welcome
this suggestion. Oberon Microsystems originally planned a Unix release of
their product, but later dropped it. Personally, I would like to see a
"Component Pascal compatability" mode for OOC. Unfortunately, it would
probably involve quite a lot of work for Michael as maintainer of the
compiler, or some other brave volunteer. I think there would need to be a
demonstrable benefit to be returned before such an effort would be considered.

>I have read the documentations of the differences, recently, and I
>don't see any drawback, if like in BlackBox a Tool for Converting the
>sources is provided.

Component Pascal introduces some useful improvements to Oberon-2. These
improve the safety and flexibility of the language for building modular,
component-based systems. In my opinion, the important ones are:

1) Abstract types. Results in better design of object hierarchies.

2) Object finalisation. This ensures that objects correctly release
non-heap resources when they are freed by the garbage collector (eg.
operating system objects such as file handles, window handles, etc). Hans
Boehm's garbage collector supports finalisation, so this would not be hard
to add.

3) CLOSE for Modules. Module definition reads:

MODULE Test;

... definitions ...

BEGIN
  .. initialise ..
CLOSE
  .. finalise ..
END Test.

Again, this allows resources to be freed properly when modules are
unloaded. Its probably not an issue yet for OOC, since it does not support
dynamic loading of modules.

4) Implement only methods. A method can be defined as implement-only, which
means that it can only be called in the module in which it is first
defined. It may be implemented in sub-classes, but not called (eg.
Stores.Internalize, Stores.Externalize, Stores.CopyFrom)

5) LIMITED records. These can only be allocated and extended in the module
in which they are originally defined (eg. Stores.Alien). This means that
you can safely export the definition of types without users being able to
allocate and manipulate them.

>And why not go further? I think that this language
>still can be improved.

I agree. It is still possible to improve the language. The problem would be
losing compatability with existing systems. Component Pascal already does
this. Any CP program that implements type-bound procedures is not valid
Oberon-2. This is because CP requires the use of the "NEW" attribute when
introducing new methods. Oberon Microsystems did not supply an Oberon-2
compatibility mode in their compilers, so it is not possible to mix Oberon
and CP code. It is unfortunate that for a system that encourages modularity
and reuse of code, there are so many incompatible systems.

Having said that, if I were designing "Oberon-3" today, I would probably
also add the following:

1) Parametric Polymorphism. As described by Roe and Szyperski, this can be
done in a safe, efficient, modular fashion. This is particularly important
for designing container objects. Using inclusion polymorphism there can be
no guarantee that only objects of a particular type can be in a container,
and type guards are required to access the components which results in
complex code and run-time penalties. Parametric polymorphism solves these
problems while re-using existing compiled code. It can be done without
breaking modularity, and without generating more code for the client type
(as occurs with C++ templates and Modula-3 generics).

2) Interfaces. This is one very nice innovation of Java. Interfaces are
fully abstract classes, consisting only of method definitions. A class can
implement multiple INTERFACEs without affecting the layout of fields in its
record. Although this might be quite tricky to implement, it _dramatically_
simplifies the design of class hierarchies (eg. for an object to be
serialisable, it does not have to be a sub-class of Stores.Store: it just
has to implement the interface for Stores.Store). 

A good Interface model is important for interacting with
language-independent object models such as CORBA and DCOM. This will become
more important over time. It is likely that future APIs will be defined in
object-oriented terms: that is, using an object/method model rather than a
traditional "flat" procedural model. This is already happening on Windows
systems: Most new APIs (eg. DirectX, speech APIs, etc) are defined in terms
of COM or ActiveX (which is built on top of COM). This presents the
challenge of how to map language objects onto systems like DCOM and CORBA.
So far, BlackBox (via its Direct-To-COM compiler) is the only Oberon
environment to attempt this.

3) A Metaprogramming facility. For example, the Refs system described by
Steindl for Oberon V4.

The problem for the Oberon community is that Java has solved many of the
safety problems with languages like C++. Thus, Oberon may not have the
attractiveness that it once had as an alternative to "mainstream"
programming environments. Personally, I still like the simplicity and
efficiency of Oberon. However, if someone is going to put effort into
developing languages, compilers and libraries there needs to be some sort
of benefit as a result. The benefit of Oberon over C/C++ is very clear in
my mind. The benefit of Oberon over Java is not so clear.

Just a few thoughts.

Cheers,
- Stewart