[Oberon] Oberon for a C++ user.

[Felix Friedrich]

Hi Jörg

That is correct. At the same time it does not solve all problems. If you 
have any other reference to the code of a module, for example via some 
procedure variable, the code can crash or, even worse, provide some 
other unexpected behavior.

For this reason I consider the unloading of modules a very useful 
feature for a software development phase. I would rather not use it as a 
feature of some product in the field.

Felix


> Wojtek
>
> Every module has a counter where it registers how many times it got imported. As long there is a module X importing module Y you cannot unload module Y. You first have to unload module X, the counter of Y is decremented and when it is 0 you can unload Y.
>
> Jörg
>> Am 27.09.2016 um 07:44 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>>
>>> Actually Oberon modules ARE allocated on the heap. This is the beauty of Oberon that you can load and unload them dynamically.
>> Yes, but only a single copy. Duplication of the same code makes no sense. In that sense modules are different from objects.
>>
>> BTW, how about safety of unloading the code? In BlackBox they do not unload, they deactivate. How about the Oberon System?
>>
>> W.
>>
>> Jörg
>>
>>> Am 27.09.2016 um 07:14 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>>>
>>> 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.
>>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=pyCxw3iKYPlDKPXz87aWroZImdqWNCDNXUGMfb31jAU&s=TlEt17qNWyHP1HTG1paIrYBeocYUegpYyFZqjQLIzRM&e=
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon