[Oberon] Should hidden re-imports be able to coexist with identifiers
andreas_pirklbauer at yahoo.com
Sat Jul 16 16:52:07 CEST 2022
> Luca Boasso luke.boasso at gmail.com Sun May 16 03:13:24 CEST 2021
> I have two problems in forcing the programmer to think about import ordering:
> 1. It does not scale. If you have big systems it is hard to hold in your
> head all the import relationships. It is better to have the compiler figure
> it out for you and do the proper checks.
> 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.
I now couldn’t resist and have actually implemented a variant
of ORB that removes the “invalid import order” restriction and
allows hidden re-imports to peacefully coexist with identifiers.
It was surprisingly straight-forward to implement, only about
15-20 lines of code. Details are here (variant 2):
The key idea is to simply propagate reference numbers of
re-exported types from the original module throughout the
module hierarchy (I just add to the information that is
already output for re-exported types). When later a
type T is imported explicitly, one only needs to check
that particular reference number had previously been
re-imported. And if so, the type is discarded after
having read it from the symbol file.
PS: This would make a nice exercise for a compiler course.
Not much to code, but some thinking is required for sure.
More information about the Oberon