[Oberon] Oberon for a C++ user.

[Andreas Pirklbauer]

Felix,

(writing this on iphone while travelling, pls apologize typos)

That is absolutely correct. The "old" B is no longer there, but there are still elements created by the "old" B in the data structure rooted in base module A.

I would say this:

1) Module C *should* only be able to remove elements of the "new" B

2) The fact the elements from the "old" B are still around is a problem that should only concern the "old" B

3) In Experimental Oberon, the module block of the "old" B is still around in memory (i.e. is not released) *precisely* because there are still type references (type tags) in the base module A pointing to type descriptors located in the module block if the "old" B. so the code of the "old" B is also still around, even though a "new" B has been loaded in the meantime and is now *the* one B that is showing up in the module list displayed by System.ShowModules (note that the "old" B is also shown, but with an asterisk).

4) So how can the elements of the "old" B be removed? The answer is they can't. It's a programming error. However, the base module A itself *should* be able to remove *any* element created by either the "old" B or the "new" B. I have actually played with this a little bit, with A = module Viewers. Viewers.Close closes any viewer (= A.Close) and removes it from the data structure rooted in Viewers (=A). In doing so it might for example call a "close" method that could be an installed procedure that is different for each extension. In THAT case, module A would call the exact right "close" method (a kind if finalizer but not for a module, but an object) - namely the "old" one for the "old" B, and the "new" one for the "new" B.

 So it *can* be handled, but one has to program for it. True.

Will get back to you once I'm in front of a computer.. will run your code through Experimental Oberon. It's worth pondering this example some more..

Another comment: Have you thought about a generic persistence mechanism: B "persists" an object so that it is now in fact "owned" by A (think: you download a pdf document in your mail client, then tap "Save to Documents" - now the Documents app "takes over" and now owns that pdf document, and the mail app can be deleted).

I want to experiment with that in Experimental Oberon and realize exactly that (in a generic way).

Andreas


Sent from my iPhone

> On 17 Nov 2016, at 16:36, Felix Friedrich <felix.friedrich at inf.ethz.ch> wrote:
> 
> Andreas
> 
> I imagine the following, admittedly artificial, setup:
> 
> MODULE A contains a list L of some R0 = POINTER TO RECORD ... END 
> For example A provides base type and repositories of geometric figures.
> 
> MODULE B imports A and declares R1 = POINTER TO RECORD (A.R0) .. END; 
> For example R1 describes a circle.
> 
> MODULE C traverses the list of A identifying every B.R1 element with a type test:
> IF element IS R1 THEN (* e.g. remove it from the list A.L *) END; 
> For example C constitutes a graphics program providing a mechanism to remove all circles from a plot.
> 
> The problem is that if B is unloaded after some circles had been deposited in A.L and if B is loaded again and only then C is becoming active, it will only remove elements from the new B but not of the older B: there will still be circles in the plot.
> 
> 
> Minimal Test code:
> 
> MODULE A;
> TYPE R* = POINTER TO RECORD END;
> VAR r*: R;
> END A.
> 
> MODULE B;
> IMPORT A;
> TYPE R* = POINTER TO RECORD(A.R) END;
> VAR r: R;
> BEGIN  
>     NEW(r);
>     IF A.r = NIL THEN
>         A.r := r;
>     END;
> END B.
> 
> MODULE C;
> IMPORT A,B;
> BEGIN
>     IF A.r IS B.R THEN A.r := NIL END; (* problem: type test refers to "new" version of B.R while an instance of an old version of B.R is still existing. *)
>     ASSERT(A.r = NIL);  
> END C.
> 
> Load Module C.
> System.Free C ~
> Load Module C. (--> TRAP)
> 
> Rgds
> Felix
> 
> 
>> Felix,
>> 
>> that appears to be a solvable problem though. Two comments:
>> 
>> 
>> (i) In order to keep "old" types and methods around, it suffices to keep older versions of a module block (containing both its type descriptors and its procedures) around in main memory, as long as there are references to them from the remaining part of the system.
>> 
>> 
>> (ii) Even if an "old" version of a module passes a pointer around and that pointer suddenly ends up in a newer version (of potentially the same module), it is not really a problem (I think, but happy to be proven wrong) - so long as the "old" type descriptors and methods are still available in memory.
>> 
>> 
>> Note that "old" methods will of course also access the "old" record and the "old" type descriptor for that record type, so there doesn't seem to be problem in principle. That of course needs to be taken with a grain of salt, just like one needs to take module interfaces with a grain of salt. If the newer version of a module doesn't actually change the module *interface* (i.e. meaning that clients do not need to be recompiled), but significantly changes the semantics of its implementation, there may be issues. All that is really guaranteed is that the module *interface* doesn't change - so even with modules, it is the programmer's responsibility that the *semantics* between multiple versions are "consistent". I'd say it's the same with records and methods.
>> 
>> 
>> PS: I have implemented (i), but have not tested an example for (ii) yet. So if someone supplied a short test program for that in this forum, I'd be happy to test and then report on it.
>> 
>> 
>> Andreas
>> 
>> -------------------------------------------------------------------------------------------
>> From: Felix Friedrich felix.friedrich at inf.ethz.ch 
>> Tue Sep 27 19:11:59 CEST 2016
>> 
>> > 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
>> 
>> 
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161117/98987055/attachment.html>