<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br>Am 03.03.2019 um 22:49 schrieb Jörg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br><br></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">Oliver<div><br></div><div>Chapter 12.6.2 of this document <a href="https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf">https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf</a><div>explains why.</div><div><br>„Objects exported from some module M1 may refer in their declaration to some other module M0 imported by M1. It would be unacceptable, if an import of M1 would then also require the import of M0, i.e. imply the automatic reading of M01's symbol file. It would trigger a chain reaction of imports that must be avoided. Fortunately, such a chain reaction can be avoided by making symbol files self-contained, i.e. by including in every symbol file the description of entities that stem from other modules.“</div></div></div></blockquote><div><br></div><div>Yes, this was - sort of - established with my first example: when it comes to type extensions „across module boundaries“ it suffices (from a programmer‘s view) to only import the module which „lastly“ (in the inheritance chain) defined the type.</div><div><br></div><div>And the above chapter confirms my assumption that modules are really „stand alone“, that is „they know and export“ everything the client module needs to know in order to use them (without having to recursively parse all dependencies).</div><div><br></div><div>And the inherited types („duplicated“ in the module’s symbol table, in order not to have to parse the dependencies) are most likely also marked as „duplicates from module X“, such that...</div><div><br></div><blockquote type="cite"><div dir="ltr"><div>But if you LATER import M0, these objects being previously imported by M1 would have to be merged to the orginal elements of M0. If you don‘t merge, the symbol table would have TWO different entries of the same type.</div></div></blockquote><div><br></div>... they can easily be „replaced“ with the „real declaration“ of module X, but „easily“ only if module X had /already/ been imported before! In order not to have duplicate symbols in the compiler‘s symbol table.<div><br></div><div>While it would be possible to „re-merge“ with previously imported (and already parsed) modules each time a new module is imported, that‘s clearly more complicated.</div><div><br></div><div>That is exactly the technical explanation I was looking for! (And it was actually already given by Peter before, so thank you all).</div><div><br></div><div>Thanks a lot :)</div><div> Oliver</div><div><div><br></div></div></body></html>