[Oberon] Oberon for a C++ user.

[Skulski, Wojciech]

Lars:

>An interesting thought: if one were to make a module allocated at run time
>would this offer anything useful or different than an object being
>allocated? 

A module provides executable code. There is only one copy of the module's code. An object provides data and pointers to the code, but it does not provide the actual code. There can be multiple copies of the object. Each copy can provide different data, but the same pointers to the same code. Note that in this description I have in mind Oberon-2 objects rather than Oberon-1 objects. Oberon-1 objects are more difficult to understand because the pointers to the code can be installed at run time. Note however, that Oberon-1 objects do not provide the code. Just the pointers.

>Or would we reinvent object oriented programming if modules
>could be allocated on the heap?  If we just reinvented objects, now we
>know exactly what modules are: design time objects without any heap
>allocation at run time.

You put the module on the heap with its code, because it is the module's goal to provide the code. OK. Now you need to execute that code from the heap. OK. You allocate another copy of the module on the heap. So you put the same executable code on the heap for the 2nd time. Now you can execute it. (If you cannot, then allocating the code would make no sense.) So now you have two copies of the same executable code on the heap. It makes little sense.

W.