How to modularize – structure suggestions #215
When splitting the gcovr script into multiple smaller modules, how should we divide them? In this issue, we can discuss design decisions before settling on a particular choice.
The modularization that was done on the dev branch uses this structure:
I'd prefer a slightly different design:
So I'd probably do:
One thing that bothers me with both of these approaches is the rather generic module names like
Are there any alternative suggestions? Any weaknesses with the proposed structures?
Once we've decided on a design, implementing the modularization is going to be fairly easy. Further refactoring can come afterwards.
The text was updated successfully, but these errors were encountered:
I'd probably go with a slightly different design
This would allow 3rd party generators if needed. One might even think to get a
Maybe add a namespace
Regarding plugins and a public API: that is a direction I am open to, but it's too early to implement any of that as part of modularization. Plugins also add many questions of their own, such as “how do we parse command line arguments”. However, I do want to find a structure that allows us to introduce plugins etc. without a second large reorganization. Plugins can be implemented through setuptools entrypoints which does not require namespace packages.
“Generator” is a perfect name for the output formats. I think names like
I'm not sure what the difference between
What I'm suggesting is of course a direction and I don't expect to get a stable API or Plugin definition for the next version. All I'm saying is that - and as you said yourself - if it's a direction worth taking, it shall be taken under consideration when defining the new design not to redo things all over again. The question you raised regarding plugin & command-line arguments was one that came to my mind when I wrote this. It adds complexity and does not need to be addressed in a first step.
What I had in mind was
Of course, the logic in