Change Details

We have several similar but distinct methods of creating an object based on some kind of static description: * CentralIdLookup, SessionManager and AuthManager providers, LoggerFactory and MonologSpi, and most ObjectCache related code (cache declarations in EtcdConfig, MultiWriteBagOStuff and ReplicatedBagOStuff) use [[https://www.mediawiki.org/wiki/ObjectFactory|`ObjectFactory::getObjectFromSpec`]]. Also Wikibase for declaring unit conversion storage classes. * ObjectCache itself (`ObjectCache::newFromParams`) has its own syntax, which also uses `class` and `factory` properties (along with lots of caching-specific ones) but not `args`, `calls` etc, and unlike ObjectFactory passes the spec to the factory. * `ApiModuleManager::addModules` uses the `class` and `factory` subset of the ObjectFactory syntax, except it can take a class name instead of an array as a shorthand. * `ResourceLoader::getModule` / `$wgResourceModules` uses `class` / `factory` parameters; like ObjectCache, the spec includes other things and is passed through to the factory. (Also you can pass an already instantiated object via the `object` key.) * `$wgApiFeatureUsageQueryEngineConf` uses `factory` / `class` but with some specific expectations on what parameters should be passed. * StubObject takes a classname or callable and a parameter array. But we are trying to move away from stub objects anyway. * Scribunto's `$wgScribuntoEngineConf` also uses `factory` / `class`. There is also declarative callback specification, most notably for hooks, which is not quite the same thing but there is a large overlap in use cases (see e.g. {T171515}). It would be nice to use the same syntax everywhere, so developers don't have to memorize many different ways of declaring classes. Also, many of these lack the same features (e.g. no support for getting the factory from the service container) so a single class responsible for object construction would make improving them easer. ObjectFactory seems like the obvious candidate for that. One potential problem is that most of these use an array that mixes object construction related properties with other properties (to be passed to the class or factory) which makes adding new properties in the future unsafe.

We have several similar but distinct methods of creating an object based on some kind of static description: * CentralIdLookup, SessionManager and AuthManager providers, LoggerFactory and MonologSpi, and most ObjectCache related code (cache declarations in EtcdConfig, MultiWriteBagOStuff and ReplicatedBagOStuff) use [[https://www.mediawiki.org/wiki/ObjectFactory|`ObjectFactory::getObjectFromSpec`]]. Also Wikibase for declaring unit conversion storage classes. * ObjectCache itself (`ObjectCache::newFromParams`) has its own syntax, which also uses `class` and `factory` properties (along with lots of caching-specific ones) but not `args`, `calls` etc, and unlike ObjectFactory passes the spec to the factory. * `ApiModuleManager::addModules` uses the `class` and `factory` subset of the ObjectFactory syntax, except it can take a class name instead of an array as a shorthand. * `ResourceLoader::getModule` / `$wgResourceModules` uses `class` / `factory` parameters; like ObjectCache, the spec includes other things and is passed through to the factory. (Also you can pass an already instantiated object via the `object` key.) * `$wgApiFeatureUsageQueryEngineConf` uses `factory` / `class` but with some specific expectations on what parameters should be passed. * StubObject takes a classname or callable and a parameter array. But we are trying to move away from stub objects anyway. * Scribunto's `$wgScribuntoEngineConf` also uses `factory` / `class`. There is also declarative callback specification, most notably for hooks, which is not quite the same thing but there is a large overlap in use cases (see e.g. {T171515}). It would be nice to use the same syntax everywhere, so developers don't have to memorize many different ways of declaring classes. Also, many of these lack the same features (e.g. no support for getting the factory from the service container) so a single class responsible for object construction would make improving them easer. ObjectFactory seems like the obvious candidate for that. One potential problem is that most of these use an array that mixes object construction related properties with other properties (to be passed to the class or factory) which makes adding new properties in the future unsafe. ---- [x] Update ObjectFactory to handle all use cases (dedbaec and c4abcd1) [x] Add ObjectFactory to MediaWikiServices (a11ad5f) [ ] Convert use cases to use the ObjectFactory service [ ] Things using static ObjectFactory (CentralIdLookup, SessionManager, AuthManager, LoggerFactory, MonologSpi, "most ObjectCache related code") [ ] ObjectCache itself [ ] ApiModuleManager [ ] SpecialPageFactory [ ] ResourceLoader [ ] StubObject? [ ] ApiFeatureUsage [ ] Scribunto

We have several similar but distinct methods of creating an object based on some kind of static description: * CentralIdLookup, SessionManager and AuthManager providers, LoggerFactory and MonologSpi, and most ObjectCache related code (cache declarations in EtcdConfig, MultiWriteBagOStuff and ReplicatedBagOStuff) use [[https://www.mediawiki.org/wiki/ObjectFactory|`ObjectFactory::getObjectFromSpec`]]. Also Wikibase for declaring unit conversion storage classes. * ObjectCache itself (`ObjectCache::newFromParams`) has its own syntax, which also uses `class` and `factory` properties (along with lots of caching-specific ones) but not `args`, `calls` etc, and unlike ObjectFactory passes the spec to the factory. * `ApiModuleManager::addModules` uses the `class` and `factory` subset of the ObjectFactory syntax, except it can take a class name instead of an array as a shorthand. * `ResourceLoader::getModule` / `$wgResourceModules` uses `class` / `factory` parameters; like ObjectCache, the spec includes other things and is passed through to the factory. (Also you can pass an already instantiated object via the `object` key.) * `$wgApiFeatureUsageQueryEngineConf` uses `factory` / `class` but with some specific expectations on what parameters should be passed. * StubObject takes a classname or callable and a parameter array. But we are trying to move away from stub objects anyway. * Scribunto's `$wgScribuntoEngineConf` also uses `factory` / `class`. There is also declarative callback specification, most notably for hooks, which is not quite the same thing but there is a large overlap in use cases (see e.g. {T171515}). It would be nice to use the same syntax everywhere, so developers don't have to memorize many different ways of declaring classes. Also, many of these lack the same features (e.g. no support for getting the factory from the service container) so a single class responsible for object construction would make improving them easer. ObjectFactory seems like the obvious candidate for that. One potential problem is that most of these use an array that mixes object construction related properties with other properties (to be passed to the class or factory) which makes adding new properties in the future unsafe. ---- [x] Update ObjectFactory to handle all use cases (dedbaec and c4abcd1) [x] Add ObjectFactory to MediaWikiServices (a11ad5f) [ ] Convert use cases to use the ObjectFactory service [ ] Things using static ObjectFactory (CentralIdLookup, SessionManager, AuthManager, LoggerFactory, MonologSpi, "most ObjectCache related code") [ ] ObjectCache itself [ ] ApiModuleManager [ ] SpecialPageFactory [ ] ResourceLoader [ ] StubObject? [ ] ApiFeatureUsage [ ] Scribunto