[Oberon] Oberon for a C++ user.

[Stéphane Aulery]

Le 29/09/2016 à 20:22, Skulski, Wojciech a écrit :
>> ...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?

What you say is surprising. There are probably a good reason to dismiss 
this problem. Anybody kwnow why please?

-- 
Stéphane Aulery