<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:small;"><div><div>> On Monday, July 31, 2017, 7:37:51 PM GMT+2, Paul Reed <paulreed@paddedcell.com> wrote:</div><div><br></div><div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;">> > The latest RISC5 compiler handles this similar to the original Oberon</span><br clear="none" style="color: rgb(38, 40, 42); font-size: 13px;"><span style="color: rgb(38, 40, 42); font-size: 13px;">> > compiler...the key is simply the sum of all bytes in the symbol file,</span><div class="ydp41cf968dyqt4111712094" id="ydp41cf968dyqtfd51099" style="color: rgb(38, 40, 42); font-size: 13px;"><br clear="none">> > i.e. really is a checksum.</div><br clear="none" style="color: rgb(38, 40, 42); font-size: 13px;"><span style="color: rgb(38, 40, 42); font-size: 13px;">> So the more fine-grained feature of OP2 can be achieved, at least</span><br clear="none" style="color: rgb(38, 40, 42); font-size: 13px;"><span style="color: rgb(38, 40, 42); font-size: 13px;">> cosmetically, by careful choice of the new identifier names. ;-)</span><br class="ydp964fbae0Apple-interchange-newline"></div></div></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;">Yes, if you know what you are doing, that's possible. You can even trick the system to *believe* that the symbol file has not changed when in fact it has. </span><span style="font-size: 13px; color: rgb(38, 40, 42);">However, that is hardly in the spirit of the method used. It is used because it turns out that despite its crudeness and simplicity (calculation of the key is implemented in two (!) lines of code in procedure ORB.Export), </span><span style="font-size: 13px; color: rgb(38, 40, 42);">it works surprisingly well in practice. Indeed, I have yet to "accidentally" create a symbol file with the same key for different interfaces. But it can happen,</span></div><div dir="ltr"><br></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;">To achieve the more fine-grained feature of OP2, one would need to bring the OP2 to the Oberon on RISC compiler. If you are interested, you can study procedure OPT.OutObj in the OP2 compiler (OPT is the name of OP2's table handler and corresponds to ORB for RISC Oberon). </span><span style="color: rgb(38, 40, 42); font-size: 13px;">In essence, OP2 manages a stack of so-called "extension layers" (repeated extensions of an interface results in a multi-layered interface, and when you only add layers to existing interfaces, clients are not invalidated). In the symbol file, there are so-called "stoppers", which simply consist of a tag following by a fingerprint of the layer. So a symbol file with 7 layers will have 7 fingerprints. The details are described in the PhD thesis "Separate Compilation and Module Extensions" by R. Crelier.</span></div><div dir="ltr"><br></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;">Even though it is relatively easy to update an existing Oberon compiler on RISC to this "layer model", I would refrain from doing so. It has a number of drawbacks, most of which are outlined in the PhD thesis. In addition, I would add this: Even though it will allow you to extend interfaces *without* invalidating clients, this is a rather narrow use case. What about if you make changes to an *existing* procedure? This is not an extension. So clients *will* be invalidated. Any yet, it should not invalidate clients that do not make use of the modified procedure.</span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;">This is why I have played with computing a key (checksum) for *each* object (ORB.Object) and *each* type (ORB.Type) in the symbol file and simply *add up* exactly those that are imported when compiling a client. That way one can exactly pinpoint when an interface change *actually* affects a client. However, the linker is a tick more complex... I have yet to find a compelling enough solution worth publishing.</span></div><div dir="ltr"><br></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div dir="ltr"><span style="color: rgb(38, 40, 42); font-size: 13px;"><br></span></div><div id="ydp41cf968dyahoo_quoted_2243531701" class="ydp41cf968dyahoo_quoted"><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;"><div><div dir="ltr"><div class="ydp41cf968dyqt4111712094" id="ydp41cf968dyqtfd23333"><br clear="none"><br clear="none"></div></div></div></div></div></div></body></html>