I swore there was an issue discussing this but I can't find it, so I'm making it now.
Basically, it would be nice to be able to initialize only part of a Context... for example, having graphics with no audio or such. We're already partially set up for that by having sub-Context objects. The trick is doing it without sticking Option and unwrap() everywhere.
I think it would be better to make each sub-context a trait object, and then we can, for example, have an AudioContext that uses rodio to play sounds, and a NullAudioContext that has all the same methods but just does nothing with them, or has any calls to them panic at runtime. This way we don't have to check to make sure the context is valid Every. Single. Time. We. Touch. It.
That said, trait objects have their own limitations, soooo. This might be harder than it looks, and it doesn't look easy.
icefoxen
All 5 comments
Just wanted to tag #431 here since this sort of refactor would greatly improve the achievable isolation and make testing much more convenient.
onelson
on 12 Oct 2018
@icefoxen I'd be interested in looking into this (with some mentoring/guidance from someone).
maxdeviant
on 20 Oct 2018
@maxdeviant Awesome! The easy place to start, take a look at #487 and see how that works, then try to do something similar with another subsystem. Probably the next easiest to start with would be the audio context. Just hit me up here or on IRC or Discord or such if you need more guidance than that. :-)
icefoxen
on 20 Oct 2018
@icefoxen As part of this modularization, I was thinking a bit about the pros/cons of genericizing the context traits enough so that they aren't tied to a particular crate. Cause right now even though the context is more modular, it's still tied to a particular implementation (e.g., gilrs for gamepad input and rodio for audio).
I don't know if it's feasible or aligned with the goals of ggez to do that, but I can see some definite benefits. It would make it easier for people to plug-n-play with different libraries and make it easier to stub things out for unit testing.
Just some food for thought :wink:
maxdeviant
on 20 Oct 2018
It is squarely on the list of "it would be cool but I don't actually care enough to do it right now". Might happen for the sake of unit testing, but...
... actually, there might be sending real merit to it. Might be worth playing with more. The worry is basically being forced to paper over subtle incompatibilities. We do enough of that already.
icefoxen
on 21 Oct 2018
Related issues
Catvert
路
5Comments
blofroth
路
5Comments
Joe23232
路
4Comments
TakWolf
路
4Comments
Kasran
路
3Comments
Most helpful comment
It is squarely on the list of "it would be cool but I don't actually care enough to do it right now". Might happen for the sake of unit testing, but...
... actually, there might be sending real merit to it. Might be worth playing with more. The worry is basically being forced to paper over subtle incompatibilities. We do enough of that already.