Roan Kattouw
<roan.kattouw(a)gmail.com> wrote:
2010/9/22 Trevor Parscal
<tparscal(a)wikimedia.org>rg>:
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
sort of design would also make light work of adding extensions to core.
Making MediaWiki more modular won't magically make it possible (or
even desirable) to write any old feature as an extension. Some things
will still have to go in core and some things we'll simply /want/ to
put in core because making them extensions would be ridiculous for
some reason.
I'd rather have MediaWiki build on some classes & object instances
with a clear responsibilities, Inversion of Control and possibility
to test each _object_ separately without causing interference
to other components. Discussion what's core/extension is to me
secondary. Maybe at some point "hooks" as we know them will
not be needed, we could be able to use interfaces as
provided by the programming language instead of hooks,
possibly (yes, I'm dreaming) tied together by something like
PicoContainer.
Even still, those interfaces *will* change and it would be
good if developers could refactor the code in the core
and extensions at the same time.
I don't why we really duplicate so much functions even
within core (API vs. standard special pages for example).
But that's probably the issue to be solved in phase4 :)
So before asking how much to add into core, maybe we should
first clean up some, and then possibly add. Or sometimes
adding something (like a proper multi-wiki configuration
management $wgConf++) may clean up and simplify some things
inside core.
//Marcin