[Oberon] Should hidden re-imports be able to coexist with identifiers
andreas_pirklbauer at yahoo.com
Sun May 16 08:33:02 CEST 2021
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon