[Scummvm-devel] SDL backend modularization remarks

[vgvgf]

Hi Max,

> If the classes involved are completely independent from each other (seems to be the case
> to me), then of course there is no need to rename the feature methods for each. However, I
> still wonder whether we really need to have empty feature check methods in every
> "Manager" ? I'd prefer adding them only if we determine that we *really* need them ;). In
> particular in the "mutex manager", I have a hard time to imagine we'd ever need them --
> and if we *do* need them, we can still add them, in a way that suits our hypothetical future
> needs optimally.
I added those feature methods just for the case they are needed in a
future, I'll delete them from the managers like mutex and others that
have it not probable for using them.

> Likewise, I am not quite sure what purpose DefaultAudioManager serves, it seems to be an
> empty class inserted between Audio::MixerImpl and hypothetical subclasses of it. Again, I
> fail to see the purpose of this -- note, I am not saying there *isn't* one, maybe, I just don't
> see if, and your code and its comments don't really give one, either :).
Maybe I should get rid of it, and stick with the actual
Audio::MixerImpl, as the main purpose was to provide the feature
methods, and making it a non copyable class, as other managers.

> The long term plan would in fact be to get rid of the Audio CD methods in OSystem
> completely, in favor of a revised AudioCDManager, as described in my previous post :).
I have been looking in to the code, and it seems that the actual
AudioCDManager singleton isn't used largely, and the calls to it can
be easily redirected to a improved AudioCDManager in OSystem, so I'll
be working on this way better.


I have also been thinking that the base backend could be extended,
adding initialization code for the default managers, and creating
wrapping functionsin the backend for the managers functions. This way,
a backend would only need to initializate its personal backends and
some other code, while it won't need to override all functions from
OSystem and oly a few.

Regards,
Alejandro