Why is ImageLoader a singleton?

[Ixrec]

In another thread (http://en.sfml-dev.org/forums/index.php?topic=17106.msg123011#msg123011) someone pointed out that SFML has a "global" variable in the form of the ImageLoader singleton, presumably implying that globals aren't really that bad.  So I looked at the ImageLoader code for a minute to see if there was an obvious reason for that which I could mention in my response...and I couldn't find one.  The ImageLoader class appears to have no state, doesn't inherit from anything with state (there's only an sf::NonCopyable), its constructor/destructor are empty, and I didn't see any static variables or lazy initialization going on in the methods, so it seems like this might as well be a class of only static methods.

So purely out of curiosity, why is ImageLoader a singleton?  Did I miss something, or is it just historical reasons?

[Hiura]

Probably historical reasons since this file has been around for years and years. It was already on the svn before we move to git so you can find it in the first commit. https://github.com/SFML/SFML/tree/2f524481c15e2a91099bf0bb138b0ddb21451d92

I guess the intention was to have a similar design to FontLoader, which has at that time some private data members. Now it could be interesting to review the design, of course. 

However, singleton are not always evil. I'd say it's fine to have some as long as you don't have interdepencies between singletons. But that just a rule and sometimes rules can be broken for a wider reason. I prefer to reason in terms of «who owns what?». If the answer is nobody or everybody then a singleton *might* (not necessarily) be an appropriate design.

[Laurent]

When it was first created, it had an internal state to manage, if I remember correctly. But yes, we could probably get rid of this singleton and only use static functions now.