On 11/05/2016 13:52, David M. Lloyd wrote:
In practice this happens a lot. A module's dependency graph depends
just as much on the environment as it depends on the classes in the
module (if not more so). Modules are merged and split, replaced with
compatibility stubs, renamed, etc. If you have to recompile every
module for every environment, a lot of the benefit of modularity and
compatibility-by-ABI is lost; changes to a module in an environment
would lead to a massive cascade of recompilation.
The module system can support many refactoring scenarios, including
merging and splitting. I can see myself refactoring modules that I
maintain, I'm less sure that I want to refactor modules coming from
other projects. If I found myself refactoring modules from elsewhere
then I would expect to have to build and test those modules, it would be
strange not to do and I don't understand how you can get away with this
when changing code in those modules. It might be useful if you could lay
out a specific scenario as it may be that we are talking completely
different things.
-Alan.
