On Tue, Sep 21, 2010 at 11:34 PM, Trevor Parscal <tparscal(a)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(a)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(a)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".