I agree with Paul that this is orthogonal to the compilation cascade phenomenon.
In my opinion, putting PRIVATE entities in a module does not make much sense (yes, I know my example does it, but it is a quick adaptation of an existing code, not a clean design). If the main MODULE only contains the public interfaces, then all those PRIVATE entities really belong to the submodule together with the implementation(s) that use them. Even though within the submodule they can not formally have the PRIVATE attribute, they would still be invisible outside the submodule, therefore the end result would be the same. I have not yet enough experience to say whether I am totally comfortable with submodules as they are; however it seems to me that most of the doubts voiced so far depend more on programmer's discipline than on language facilities. Salvatore Il giorno gio, 23/07/2015 alle 10.37 +0200, Paul Richard Thomas ha scritto: > Dear Damian, > > I do not think that there is any effect on compilation cascades. As > long as the private part of the module file remains unchanged, it will > not be recompiled if a descendant submodule is modified. Naturally, > the size of the module file is increased but, if one is careful, this > is not a big deal. A gotcha, which I will have to emphasize in the > documentation occurs if another module file is used and its symbols > are not exposed by public statements. If there are large numbers of > symbols this can have a big effect on the size of the module file. I > noticed this, when examining one of gfortran's testcases where the > ISO_C_BINDING intrinsic module is used. Generous sprinklings of USE > ONLYs are required to keep the module file sizes under control. > > I am not over enthusiastic about using compilation flags to uphold > standards either. > > Cheers > > Paul
