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