Hey,
you're adding in a whole new set of incompatibilities.
How so?
Extensions that use any of these extension libaries now depend on the version of MediaWiki and the version of the extension. That's a new set of dependencies that can be incompatible now.
It adds a component as dependency yes. It however does not add code as dependency. One of the main reasons for creating well designed components rather then throwing everything into one bucket is that it minimizes source code dependencies. If you minimize dependencies (as a good programmer should do on all levels), you also minimize the things that can cause compatibility conflicts. It thus certainly benefits the user.
Imagine you have a package P, which contains components A, B and C. Only package P is versioned and released. That it could be split into 3 packages is a detail not visible to the end user. A is stand alone, B depends on A and C depends on A. You want to install extension E0 that depends on P v1.0 or later. In particular, it depends on B, though again, the end user does not know this. You want to make this install on a wiki where you already have E1 installed. E1 depends on P v0.5 to v0.8. Internally it only cares about C. This situation means you can in fact not install E0 and E1 at the same time. The only reason for this is because to many things are packaged together. If B and C where in their own packages, there would be no issue.
So one can for instance go from depending on package ABC that contains sub components A, B and C to depending on A and B. That's two packages instead of one if you look at it naively, though two components instead of 3 on closer investigation. It is quite bad to force users to care about C while there is no reason for doing so. They'll be affected by any issues that occur in C for no good reason. Every time ABC has a new release because something in C had to change, users will have to deal with this release, since to them it is not visible this is pointless.
These are simple examples, with one component that could be split into 3. The problems for the user get significantly worse if one throws more things together and as this problem is replicated in the dependency chain.
Maintaining MediaWiki installs is already relatively difficult, due to a
lack of extension management. Many extensions are also poorly maintained, and just getting an extension that works with your version of MediaWiki reliably is hard. Upgrades are incredibly hard due to this. Adding in another set of incompatibilities is going to make this much harder.
Like noted above, it is simply not the case more things become dependent on each other. Rather the opposite.
Another example. Take the Diff library. It does not depend on anything (except of course PHP itself). You talk about putting it into core. Imagine Diff 0.7 with MW 1.23 and Diff 1.0 gets bundled with MW 1.24. Now I have extension E0 that needs MW 1.24 or later. I also have extension E1 that needs Diff < 1.0. Again the user runs into problems. In case Diff is merely bundled with core, the user can resolve this by changing either Diff or MW version. In case they are solidly glued together, installation is again not possible for no good reason. Like the one before, this really is a toy example, that merely illustrates how problems arise. The problems users encounter in the real world are more significant.
Now you might ask, where are those problems you talk about?
just getting an extension that works with your version of MediaWiki
reliably is hard.
And finding a set of extensions that work together with that version is even harder. And you'll have hassle whenever you upgrade. I've seen this many many times, and have of course encountered it myself more then enough. After years of listening to users reporting problems and clients running into this, I have concluded that a lot of this could be avoided if people did not introduce silly dependencies.
The Diff extension is a good example how how to get it right. Initially it did not. It dependent on MediaWiki. It was throwing MWExeptions at places, its tests derives from MediaWikiTestCase and whatnot. This bound it to MW, putting in a requirement people have to deal with. This dependency has now been removed, as there really was no reason for it, thus making usage of Diff easier. Once again, this is the simplest example I could think of.
Sorry, I phrased that poorly. Here's my concern: If extension libraries are
generic enough that they could be considered core (Diff is a great example), then other extensions will likely use it like core functionality. Wikibase already is.
I already outlined how this can be problematic, depending on what you mean. If you are suggesting to merge it into core somehow, and just having one release for the whole thing, then it will cause hassle. Bundling would be better. We are already doing this with some extensions. That is something to look at on a per extension or per library basis though. Clearly we do not want to bundle every library needed for any extension with core.
In fact, we can't do this if you consider usage of third party libraries. Imagine you have this app A that uses some common library such as Monolog, and you have two delivery mechanism plugins for this app A. First you have B that is an interface to MW, second you have C that is an interface to some other system. An attempt to "assimilate" A into core is going very likely to end badly. The MW community is not doing a fantastic job when it comes to interoperability and sharing of components with the rest of the PHP world as it is. To me this is a quite unfortunate miss of opportunities.
These extensions won't get the same level of review as they would if they were core functionality.
This implies you are thinking of more then just bundling. Or not?
This is again something that will need judgement on case-by-case basis. In case for Diff, the code quality requirements are significantly higher then those of core, and these are not going to be lowered.
Is there any compelling reason that they are extensions, rather than being
added to core?
Hell yeah! See above :)
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --