The Great Refactoring, Present and Future
About one week ago, we passed the first anniversary of the superglobal removal in the o9 codebase, and incidentally also the last update on the refactoring effort in general. Some of the changes since then have been touched upon in the release announcements, and a number of others are still brewing.
But before we come to that, let's review: The original codebase of MidCOM has a long history, during which the project has accumulated its fair share of cruft, which made it increasingly difficult to keep up with the times. Therefore, the motivations outlined in the superglobal post, interoperability, Midgard 2 compatibility, maintainability, and probably a bunch of other words that end in „bility“ still apply to the changes we're working on now.
In many cases, these changes mostly consist of removing duplication, simplifying codepaths, and removing workaorunds for long-fixed bugs or shortcomings of forgotten PHP versions. As it is expected in situations like these, the urge to „rip it all out and start fresh“ struck sometimes, but for the most part, the Second System Syndrome has been avoided so far.
The main reason for this is of course the size of the codebase: Aside from the public github repo, there is an unknown number of vendor-specific applications and components, and switching them all over from one API to another just isn't realistic. At the same time, all these different consumers of framework services make a nice „reality check“ for changes that unit tests alone simply cannot provide.
So by and large, the API remained the same, with the notable exception of the superglobals, and several variables in the PHP GLOBALS array that were used all over the tree, most prominently the main configuration. These have been removed where possible, or made accessible via the superglobal replacement getter where unavoidable, but this will likely not be the end of it. Static getter methods are still part of the global state, which is, at least in the predominant technical opinion, evil.
Be that as it may, the fact remains that parts of the code are hard to test and/or hard to customize, and in many situations, the use of global state could be avoided simply by improving the code structure. Of course, this is slow work in a codebase of over 100,000 LOC, but compared to the initial Ragnaroek fork, we're down 25,000 LOC already, and there is still room for improvement.
Currently, there are several compatibility layers and switches in various places of the codebase, and the plan is to centralize them as far as possible, move them into a separate repository and to keep them stable, so that the core API can continue to evolve while old out-of-tree components still have a point of reference. Once this compat repo is set up, we will gradually move more deprecated functionality there, and probably introduce finer-grained controls for setting up which parts of the legacy API should be enabled.
This implies of course that there is a standard way to define dependencies and have them automatically installed during project setup. This can be done via Composer, but it will require a custom installer to take care of all the framework-specific idiosyncrasies. Another unsolved issue with out-of-tree components is that a number of central services assume that all code is located in the framework's central lib/ tree. There has been rudimentary support for using external components (e.g. in conjunction midcom-project-template) for a while now, and recently it saw a number of improvements, but there is still a ways to go before it will be completely seamless.
Once these issues are resolved, we could proceed to the next step, which would be a split of the codebase into smaller, more sensible chunks. In a lot of cases, this will involve further refactorings to have sane interdependencies between the various parts, but it can be done step by step, and there are a few low-hanging fruit that should provide a good starting point.
So there you have it: We've come a long way, but the todo list won't be getting shorter anytime soon. So if you're interested in speeding things up, contributions are most welcome!
There have been no comments so far.