Re: [Flightgear-devel] Abstracting/Mocking FGScenery

[Keith P. <mid...@gm...>]

Yes it looks like a half way house. I don't imagine I can create a mock 
for FGScenery without finishing cleaner dependency tree.

 From my previous expirience with systems like Osgi here some ideas :

  * Each subsystem must directly inherit from SGSubSystem. (required by
    the registrar)
  * The staticSubsystemClassId() must reside in a abstract base class
    for all implementations of said subsystem otherwise
    getSubsystem<Subsystem>() will pull in a certain Impl
  * This superclass will also include the public interface of said subsystem

I'm rather reluctant though since really implementing it will rip out 
the heart of FG and stuff like  getPagerSingleton() is sure break.

  "Ich backe lieber kleinere Brötchen"

Keith

Am 03.10.2022 um 10:17 schrieb James Turner:
>
>
> It’s a scheme done by Edward (I think) a few years ago to ultimately 
> replace the hard-coded subsystem creation and dependency code with a 
> formal definition driven by data. (Which is the names / flags you 
> see). This would allow ‘correct’ automated unload/reload of subsystems 
> with any dependant ones cascaded correctly.
>
> *But* we did not hit the point where this principle can be used 
> generically yet, because quite a few subsystems have weird edge cases, 
> so for now the main startup still uses the manual fgCreateSubsytems 
> code path. Also touching subsytem creation order is unfortunately one 
> of the prime ways to find subtle bugs because it can change the order 
> properties are created in / bound to listeners.
>