Re: [Flightgear-devel] RFC: Improving FlightGear's modularity

[James T. <zak...@ma...>]

> On 27 Nov 2016, at 17:01, Edward d'Auvergne <tru...@gm...> wrote:
> 
> I'm just experimenting with complete subsystem independence from
> globals for implementing powerful system/functional tests (which works
> with this initial rudimentary FGPythonSys experiment).  If globals
> could be reduced to the simple set of elements above, then such an
> approach would be a lot less obtuse, as the subsystem manager (or a
> dummy test suite replacement) can then consistently manage the data
> structures for all subsystems.  This would just require a way for the
> subsystem to access its current manager rather than using the
> globals->get_subsystem_mgr()->get_subsystem(name) pathway.
> 
> The reason I'm suggesting these ideas is because it sounds like Durk's
> AI and traffic ideas would benefit from true globals independence.
> The removal of the dependence on globals.hxx in subsystems would be
> the ultimate in modularity as you could then compile an accessory
> binary containing just that subsystem and only require linking to
> simgear.  This is what my cppunit and python branches do - typing
> 'make test_suite' creates and runs the 'run_test_suite' binary in the
> build directory, and this binary does not include globals.hxx.  You
> have to checkout the python branches to see this applied to a
> subsystem.

Just to be clear, I’m not saying any of this is a bad idea - I think it sounds excellent. I just think you are trying to go a final 10% that is not needed, and might be 50% more work. Retaining accessing values like the root property tree, fg_home and the subsystems via a structure /called/ globals (in a class called FGGlobals, whatever it contains) keeps the code much closer to what we currently have, and doesn’t reduce testability or modularity at all. If you want to go the additional step you are welcome but it’s going to be more disruptive for the codebase and more work for you.

Again, I see zero value in having a ‘mock’ subsystem manager - the subsystem manager does nothing on its own, it’s purely a structuring device. You don’t need to mock it, to use it in a test. There is no reason to suggest any test binary or AI/Traffic add-on would not run its own subsystem manager (and the same for timing, potentially). Of course you could build tests without requiring that, but validating the init / bind / update / unbind / shutdown is probably one of the most important things a test-harness should do for a given subsystem.

Kind regards,
James