Topic on Talk:Requests for comment/Configuration database

Singletons are really just globals in disguise. I don't really like them, but they are probably unavoidable without significantly rewriting MediaWiki. -- Bryan 145.94.184.252 13:43, 5 July 2011 (UTC)

This post was posted by Krinkle, but signed as 145.94.184.252.

Singletons do provide a few significant advantages over a set of globals ($wgFoo, $wgBar) or a global array ($wg['Foo'], $wg['Bar']). Mainly:

• Related functions can be stored and referenced together by being in the same class (rather than being put in random utility classes or global functions)
• Input/Output Read/Write is controlled rather than on the loose. A get/set function (either one-for-all or more specifically) can limit/verify/validate the input (ie. throw exception or correct value when it doesn't validate, instead of having to sanity check every time we access the configuration variable since it could be set to anything...)
  • likewise the read function is able to limit reading values based on the context or moment in execution time (ie. before hook X is fired, or if variable Y is set to Z)
• They are one step closer to an even better system.

I agree though that Singletons, when used as such, are much like globals. A better way would perhaps be a static cache of instances, ie. like Conf::newFromId('enwiki') instead of Conf::singleton() which would either load it or get it from static cache, where Conf::get('foo') would be like Conf::newFromId(Conf::defaultId)->reallyGet using Conf::defaultId which would be set during initialization of the wiki/run.

Yes they're globals in disguise, but for something like this you only need a single instance of the config object. Unless you think it's a good idea to have people construct config objects all over the place ;-)

Actually: expanding on the idea of "Contexts" a bit more...we could possibly move in the direction we did with RequestContext. Something like a WikiContext could be easily passed/made available as a member and has access to the configuration.

I was indeed thinking more along the way of a WikiContext, which should contain the configuration object, among other things like a RequestContext, getDatabase() function, getRepoGroup() function and things like that.

Well a WikiContext wouldn't necessarily have a RequestContext, but a RequestContext should always have a WikiContext. But otherwise I completely agree.

Yeah, maintenance script for instance.