Thank you a lot for all the feedback!
IMO, that's not always linked and in the case of a RessourceManager it mean exactly what it mean and everybody knows what it is exactly.
Yes, "resource manager" is a spread term, nevertheless one could describe the mechanics more clearly. For example,
thor::ResourceManager doesn't own the resources (the smart pointers do), it just provides an interface to acquire resources without the need to check if it has already been acquired. That's also why I like the name
ResourceCache.
Are there further ideas about how to name the all-in-one manager? Is "multi" an acceptable prefix? The alternative would also be to name the generic one only "ResourceCache" and find another identifier for the specific ones.
- "Provider" would be a slightly more precise name than "Manager"
That's also an option, thanks. It doesn't express the cache semantics either, but maybe that's obvious anyway...
- If you provide an all-in-one manager, you must still provide the individual ones in the public API, for people who split audio and graphics into independant modules
I'm not sure if I've understood that correctly. The all-in-one manager won't be a merge of the single SFML resource managers (like
thor::ResourceManager<sf::Texture>), but rather a frontend to interact with multiple resource types of any kind. For example, if one loads the first time a
sf::Texture, a corresponding resource manager is created internally, to which the
acquire() call is forwarded.
That is, one can actually do everything with the all-in-one manager that is possible with the single specializations, only that the API isn't constrained to one type.
- Don't bother with sf::Music and its openFromFile function, it's not a candidate for being managed by your class. It would be wrong to share sf::Music instances, you need a new instance everytime you want to play a music. And nothing's pre-loaded anyway, audio data is streamed, so there's no point keeping unused musics.
That's true, I remember this statement some time ago. The only reason to manage
sf::Music instances would be the uniformity with other resources (for example, the same exception is thrown at loading failure). But it's probably not worth to unify
sf::Music at all costs, in this respect it's a nice feature that
thor::ResourceManager<sf::Music> won't compile
And are there particular practices to consider at
sf::Shader? I have to admit I'm not familiar with shader use cases...
