I love this idea and had similar thoughts as well. :D
Sent from my iPhone > On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: > > Dear Mikael, > > It had crossed my mind also that a .mod and a .smod file could be > written. Normally, the .smod files are produced by the submodules > themselves, so that their descendants can pick up the symbols that > they generate. There is no reason at all why this could not be > implemented; early on in the development I did just this, although I > think that it would now be easier to modify this patch. > > One huge advantage of proceeding in this way is that any resulting > library can be distributed with the .mod file alone so that the > private entities are never exposed. The penalty is that a second file > is output. > > With best regards > > Paul > >> On 23 July 2015 at 17:42, Mikael Morin <mikael.mo...@sfr.fr> wrote: >> Hello Paul, >> >> Le 23/07/2015 09:46, Paul Richard Thomas a écrit : >>> >>> Since all the private entities in a module have to be transmitted to >>> their descendant submodules, whilst keeping them hidden from normal >>> use statements, I have chosen to write the module file as usual and >>> add a second part that contains the private entities. This latter is >>> only read when processing submodule statements. >> why not write them to the/a .smod file? It was its primary purpose, wasn't >> it? >> [Sorry, I followed the submodule stuff very remotely]. >> >> It's probably bad practice to put private entities in module files, at least >> now that submodules are supported. Nevertheless with your change, >> modifications made to private entities produce recompilation cascades, even >> though the public interfaces are left unchanged. >> >> Mikael > > > > -- > Outside of a dog, a book is a man's best friend. Inside of a dog it's > too dark to read. > > Groucho Marx
