Should hidden re-imports be able to coexist with identifiers
Hi Luca, You are about half way through in convincing me.. ;-) .. and now that there is an easy way (i.e. 5 lines of code) to get rid of the “invalid import order” restriction also in the PO 2013 compiler (i.e. without having to make more elaborate changes as in oberonc/Griesemer’s approach), it’s tempting indeed.
2. It breaks encapsulation. If I (module B) import a module, A, I should only care about its public interface, not how it is implemented. So if the module A re-imports types and indirectly could mess with the import order of my module B, we have implementation details leaking through. So when the implementation changes the import order of the client modules could break.
That is a strong argument indeed! In essence, what you’re saying is that the very postulate of “modular programming” itself is violated here (namely that changes in the implementation of A should not necessitate the recompilation - or in this case even the re-editing (!) of the import list - of a client module B) . Although one can also view the re-exported types of A as *part* of its interface, in the sense that if A is modified such that it now also re-exports types from another module (that it previously didn’t re-export), the “interface” of A *does* actually change - surely the symbol file of A does. Thus, a client B must - at the minimum - be recompiled anyway. It just happens not to be the “public” part of A's interface that changes, but only the “hidden” part (=list of re-exported types). So.in principle, this should not be great cause for great concern, weren’t it for the fact that (the import list of) module B may now also have to be edited (!) before it can be re-compiled. * * * The crux is: It’s the fact that the re-import mechanism is a *hidden* mechanism (i.e. not in the spirit of Oberon) that causes much of the issue. PS: I have experimented with - and even implemented - a few possible ways to try to solve the root cause of the issue instead of tinkering with its symptoms, i.e. to get rid of the re-import mechanism altogether.. e.g. by explicitly marking re-exported types in the source file or something.. ..but I just couldn’t do it (at least not in a satisfactory manner). -ap
participants (1)
-
Andreas Pirklbauer