[Oberon] Oberon for a C++ user.

[Srinivas Nayak]

> If procvar := Mod.Proc is done automatically while module loading,
> (through code sitting inside module BEGIN...END)
> we should have an automatic means of making it NIL while unloading.
> But...we don't have a place like BEGIN...END to execute when module gets unloaded!
>
> Can we have something like this...
> A  procedure UnloadMe() which a module will implement.
> And when the module is unloaded, UnloadMe() will be called.

Clemens Szypeski in his thesis "Insight ETHOS" discusses on
"Finalization" in section 2.1.4.

"Another aspect closely related to garbage collection is object
finalization. Object finalization refers to the possibility for an object to take
some final actions just before it gets removed by the garbage collector."


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 10/05/2016 01:38 PM, Srinivas Nayak wrote:
>> Peter: procedure variables are "pointers" as well, just to a piece of code instead of a RECORD.
>
> This is very much true from GC's point of view...
> Thanks for proposing GC as an alternative solution.
>
> The idea behind using GC is that,
> GC can keep the unloaded module in memory till referrers vanish.
>
> However, while using GC, we don't *explicitly* delete the object.
> We just pretend that old object doesn't exist.
> We reuse the pointer with a new object.
> That means both objects exist in memory, till GC comes.
> But we unload modules *explicitly*.
>
> And often we load a new *updated* module with same name.
> In such cases, can both old module and new module co-exist in memory, till GC comes to play?
>
> The biggest problem is, object identity is just an address,
> But module identity is its name.
>
>> Wojtek: You can also look at it from the point of view of the client/ server. At the point of assignment procvar := Mod.Proc, the client gets the asset and the server Mod makes the promise. When the server is unloaded, it breaks the promise without telling the client "I am gone, do not rely on my assets". The client thinks it still has a good asset, tries to use it, and it gets duped. The client is perfectly innocent. It was the server who broke the contract.
>
> Say, we unloaded the old server module and loaded a new
> updated server module (interface remaining intact),
> does procvar := Mod.Proc points to new updated server Proc?
>
> If answer is Yes, that means old module and new module doesn't co-exist in memory.
> Don't know if GC can help in such cases.
> Then, I think, as long as interface remains same, no problem.
> When interface differs, client or base or imported module
> has to be compiled and reloaded. So no problem.
>
> If the answer is No, that means module when loaded,
> have to always assign procvar := Mod.Proc automatically,
> may be inside module BEGIN...END.
> [Do we generally make procvar := Mod.Proc inside module BEGIN...END?]
>
> True that server broke the promise.
> So, I think, he should make procvar := NIL;
> Where and when is the problem...
>
> If procvar := Mod.Proc is done automatically while module loading,
> (through code sitting inside module BEGIN...END)
> we should have an automatic means of making it NIL while unloading.
> But...we don't have a place like BEGIN...END to execute when module gets unloaded!
>
> Can we have something like this...
> A  procedure UnloadMe() which a module will implement.
> And when the module is unloaded, UnloadMe() will be called.
>
> Hope that could be simpler to implement.
> No language change!
> Only implementation correction.
>
>
>
> With thanks and best regards,
>
> Yours sincerely,
> Srinivas Nayak
>
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/