[Oberon] Oberon for a C++ user.

[Felix Friedrich]

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/36f57b1f/attachment.html>