[Oberon] Oberon for a C++ user.

[Skulski, Wojciech]

> ...objects dynamically allocated on the heap.
Such objects can be referenced from a third module and their methods 
> (or procedure variables) can be called, but they themselves 
> don't increment the source module reference count. Thus, the module 
> can be unloaded while there are live objects pointing to its code segment.

Procedure variables appear like C pointers. Basically, they are addresses to be called. 
They are made a bit safer by requiring the type check of their parameter list at compile time.
At run time they appear just like jumps. There is no run time test whether the target of the jump
contains valid code. It is ironic because procedure variables are the only object oriented 
mechanism in Oberon-1 which was supposed to provide a safe programming model. 
But it is not safe.

Here we see that the mechanisms clashed. On one hand, procedure variables provide  
object orientation which was a big step forward from Modula-2. On the other hand, 
unloading the modules provides much needed development flexibility. 
However, the second mechanism easily leads to the run time crash of the first mechanism. 
It has been known for years.  

Oberon-2 does not suffer from the above if one uses Oberon-2 methods exclusively. 
But Oberon-2 has been denounced (I wonder why?) So we are back to the unsafe 
programming without a concerted effort to make it safe. I can see a certain irony here. 
Programming safety was supposed to set Oberon apart from C. 

I wonder if there is a way out.  Can this problem be solved within the Oberon-1 framework?

W.