On Tue, Sep 21, 2010 at 11:34 PM, Trevor Parscal tparscal@wikimedia.org wrote:
In response to recent comments in our code review tool about whether some extensions should be merged into core MediaWiki, or not. I would like to try and initiate a productive conversation about this topic in hopes that we can collaboratively define a set of guidelines for evaluating when to move features out of core and into an extension or out of an extension and into core.
Partly this is a matter of preference. I personally write things almost entirely for core -- I've never written an extension, so my only extension commits are to things that other people wrote as extensions. Other people prefer to write extensions instead of core features. As long as the code gets written and works either way, I don't think it's usually a huge deal. A lot of stuff will work fine either in core or as an extension -- this doesn't have to be made a religious issue or one where we have detailed official policies.
What I think is clear is that anything that the large majority of MediaWikis would benefit from should be enabled by default, which given our current setup means it has to be in core. I haven't looked closely, but I believe this includes a significant part of the usability stuff (although not all). MediaWiki should work as well as possible for as many users as possible out of the box, and whatever that implies for how the code is structured is what we should do. I cannot conceive of any reason why most of the features of the Vector extension should not be in core, for instance -- why would you *not* want them? Why would you ever want to disable them? ("Admins should have choice" is not a good reason by itself. Cf.: http://weblogs.mozillazine.org/bz/archives/020683.html)
Other than things you want to enable by default, here are some reasons to put some features in core rather than extensions:
* Core features are much easier for site admins to enable than extensions. It would be great if this were fixed, but currently, it's not, so it can't be dismissed. You can dismiss this reason (basically your #1) as soon as it's become irrelevant in practice, but not before. * For smaller features, it will take a lot more code to write them as extensions than as part of core. You can often add a useful core feature in less than ten lines of code -- extensions are much heavier-weight. This is unavoidable, because extensions have to have a whole bunch of metadata to specify where their code executes and so on; with core code you can just put it in the right place. * It's easier to understand how core code works in the absence of extensions, because the code is explicitly written out where it occurs. When extensions are involved, you have a wfRunHooks() line in core, which basically means "absolutely anything could happen at this point". When you run into a hook when reading code, it doesn't only complicate understanding how the code will run in practice, it also makes it much harder to change. If you want to refactor, you have to write a lot of painstaking and ugly logic to preserve the semantics of the hooks, or else just give up and get rid of them.
On Wed, Sep 22, 2010 at 4:33 AM, Trevor Parscal tparscal@wikimedia.org wrote:
Modular feature development being unique to extensions points out a significant flaw in the design of MediaWiki core. There's no reason we can't convert existing core features to discreet components, much like how extensions are written, while leaving them in stock MediaWiki.
This can be accomplished by regular old object-oriented programming. Keep all the related code in one class, and make as much possible private so that classes can only call a limited number of well-defined, well-documented, easily-understood entry points. I don't think extensions are a good model for this -- to the contrary, they're antithetical to modularity, since any extension can drastically change how any part of the program behaves (given enough hooks).
On Wed, Sep 22, 2010 at 10:17 AM, Andrew Garrett agarrett@wikimedia.org wrote:
I think that I would support allowing core features to use hooks instead of writing the code in all over the place. All you would have to do is initialise $wgHooks somewhere before LocalSettings.php is run.
Giving structural proximity to functionally-related code would make things much less confusing for new developers (and simpler for those with experience). It would allow us to declutter our core code (things like user permission checking come to mind), and it would make light work of merging extensions into core.
This is reminiscent of COMEFROM. It makes it really hard to understand what's going on if you have the code scattered everywhere. Modularity is great, but it needs to happen along clear boundaries to keep the code comprehensible -- not "anything can happen at this point".