On Thu, Oct 24, 2013 at 12:04 AM, Chad <innocentkil...@gmail.com> wrote:
> On Wed, Oct 23, 2013 at 8:44 PM, Tyler Romeo <tylerro...@gmail.com> wrote: > > > On Wed, Oct 23, 2013 at 10:54 PM, Chad <innocentkil...@gmail.com> wrote: > > > > > I've personally not been convinced of this Value/Parser/Formatter > pattern > > > but if I'm the only one I'll just keep my big mouth shut > > > > > > > I agree with this as well. The idea behind this RFC is the "hair can't > cut > > itself" pattern. > > I wish my hair could cut itself ;-) > Maybe my hair can't cut itself, but I can cut my own hair without having to find a Barber instance. ;) Looking at the RFC itself, it does seem to be following the "kingdom of nouns" model Maxsem linked to. And it has a maze of twisty little objects, all different, that tends to concern me in these proposals. Why do we need a separate TitleParser and TitleFormatter? They use the same configuration data to do complementary operations. And then there's talk about making "TitleFormatter" a one-method class that has subclasses for every different way to format a title, and about having a subclass for wikilinks (huh?) which has subclasses for internal and external and interwiki links (wtf?), and so on. High-level methods to actually do anything useful like "move a page" or "parse some wikitext" seem like they are going to need to take dozens of these objects to be able to actually do what they need to do. (And yes, I know the argument is that then the useful function should be split into multiple smaller functions with fewer arguments, to which I reply "you just pushed the problem up the call stack, you didn't solve it"). 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? 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? Somewhere in this thread someone claimed that we shouldn't have code that processes user input and then does something and then formats the output, presumably because each of those should be their own "tree". So how then does any end user actually do anything? At the top level something *does* have to do all three things, even if it does it by calling into various "trees" and each of those trees has its own branches and each branch has its own twigs and so on. 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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
