[Oberon] Oberon for a C++ user.

[Felix Friedrich]

Wojtek

Let me first of all confess that I like Oberon-2 a lot. I always thought 
it would be a good idea to reintroduce the type bound procedures on 
value types in Active Oberon. [Most important difference to Active 
Oberon in this context: methods can be defined outside the scope of an 
object, methods can be defined on records, not only pointer to records.]

However, the introduction of object orientation can aggravate the 
discussed module unloading problem, because it bascially provides 
procedure variables hidden in method tables.

When implemented correctly, the usage of methods can make sure that an 
unloaded module is not GCed because the method delegate contains a 
pointer to the object containing a pointer to its type descriptor 
containing a pointer to its module --> module would be protected from 
being GCed.

But this does not solve other problems coming from the possible 
coexistence of an old and new version of a module. If the old module 
survives, pointers could be passed around to new modules compromising 
the type system.

I think that any kind of upcall, be it via procedure variables or via 
object methods does not go well with module unloading.

Felix





> Felix:
>
> procedure variables are a known security risk. I remember lengthy discussions concerning this subject. The procedure variables are still around nevertheless.
>
> Am I right in saying that this risk was eliminated with Oberon-2? If a reference to the method exist then the module is still imported and cannot be unloaded.
>
> If the above is true then Oberon-2 should be reintroduced rather than tossed away.
>
> Wojtek
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Felix Friedrich [felix.friedrich at inf.ethz.ch]
> Sent: Tuesday, September 27, 2016 2:54 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Oberon for a C++ user.
>
> 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://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=FQko2vU0I-b5cI-5iyV-o8ggZCc1VPdfgfcTd0aeuXw&s=ciLfuD5oSoDvQbXR2uz2iWMlhurxtZUv7-ON5cpGXg0&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=FQko2vU0I-b5cI-5iyV-o8ggZCc1VPdfgfcTd0aeuXw&s=ciLfuD5oSoDvQbXR2uz2iWMlhurxtZUv7-ON5cpGXg0&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=FQko2vU0I-b5cI-5iyV-o8ggZCc1VPdfgfcTd0aeuXw&s=ciLfuD5oSoDvQbXR2uz2iWMlhurxtZUv7-ON5cpGXg0&e=
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon