[Oberon] Should hidden re-imports be able to coexist with identifiers

[Andreas Pirklbauer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20210516/db34684c/attachment.html>