>> Roan Kattouw <[email protected]> wrote: > 2010/9/22 Trevor Parscal <[email protected]>: >> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
