On 25/10/13 03:19, Brad Jorsch (Anomie) wrote: > So then the RFC proposes a "ServiceRegistry" to try to get around this > problem of everything requiring dozens of arguments. But after observing > that RequestContext already *is* this, it then argues against using > RequestContext on the basis of additional dependencies. The logical > extension of this argument is that we're not really talking about a > "ServiceRegistry" here, we're talking about a "TitleServiceRegistry" and > then we'd also have a "RevisionServiceRegistery", "PageServiceRegistry", > "UserServiceRegistry", and so on, trying to pretend there is no forest > because we can point to all the individual trees. Why not have one > ServiceRegistry, maybe even part of RequestContext, and use it > preferentially for passing services instead of just as a fallback?
The proposal as I understand it is just for a single ServiceRegistry class, rather than TitleServiceRegistry etc. I raised similar concerns at <https://www.mediawiki.org/wiki/Talk:Requests_for_comment/TitleValue#ServiceRegistry_singleton_33334> Daniel's response was: "You are right that the ServiceRegistry is again bundling all the services in a single object. The point is to restrict access to ServiceRegistry to "bootstrapping code" (e.g. in static hook handlers) only. RequestContext is used all over the code, so all the code is dependent on anything in the RequestContext. That makes me very very reluctant to add more stuff to it." > Do we > really have the need for multiple differently-configured services all over > the place in "real" code that we need to be passing them around > individually, or is it just for testing where we could as easily solve the > problem by creating a registry instance that throws errors for all the > services not needed for each test? Division of the Title class could help with features such as: * Dealing with titles in foreign wikis, with a different set of namespaces and first letter capitalisation to the request context wiki * The URL customisation needs of features like action=render and DumpHTML > The claimed problem behind a lot of this is "too many dependencies" making > things hard to test and the idea that you can somehow make this go away by > dividing everything into tinier and tinier pieces. To some extent this > works, but at the cost of making the system as a whole harder to understand > because you have to track all the little pieces. I doubt MediaWiki has > reached the point of diminishing returns on that, but I'm not really sure > that the end-goal envisioned here is the *right* division. Since the Title class is large to start with (4895 lines) I figure it can tolerate being cut up a few times without the resulting pieces becoming tiny. So, it makes an interesting test case for the approach. We will see the consequences with more clarity once the code reaches Gerrit for review, if we allow it to proceed that far. -- Tim Starling _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
