[Oberon] Oberon for a C++ user.

[Douglas G Danforth]

The code does not work for Component Pascal.
One must write for MODULE A,
either
TYPE R* = POINTER TO EXTENSIBLE RECORD END;
or
TYPE R* = POINTER TO ABSTRACT RECORD END;
However using EXTENSIBLE does indeed lead to a trap for CP.
-Doug

On 11/17/2016 7:36 AM, Felix Friedrich wrote:
> 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
>
>
>
>
> --
> 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/c351cc87/attachment-0001.html>