Look ma, no Superglobals!

One of the peculiar things about the Midgard 1/MidCOM environment was always the presence of two custom superglobals, $_MIDCOM and $_MIDGARD, where the first one was in fact an entry point to the diverse framework services whereas the second one was an array that held various information about the host setup. It was a very practical arrangement for developing components, since all functionality was easily reachable without having to worry about variable scopes, dependency injection, and other fun things like that.

But at the same time, this caused a few problems: For example, IDEs got confused and would show countless warnings for what they considered undefined local variables, code analysis tools would get the dependencies wrong, and so on and so forth. But more importantly, the custom superglobals isolated MidCOM from the rest of the PHP world, because they constituted a hard dependency on the Midgard PHP extension, meaning that MidCOM code could only run on customized servers.

Of course, the dependency on Midgard runs deeper than the superglobals, anything that is storage-related is still hardwired to the Midgard backend (more on that in some later post...), but the superglobal part always seemed a bit gratuitious. Even more so if you consider that in Midgard2 (where they are marked as deprecated), the superglobals provided are in fact just empty placeholders and all the setup has to be done by the framework anyways.

It soon became clear that a replacement would have to be found, in fact, this is one of the first tickets that were created, but since superglobals were one of the more popular constructs of the framework (the $_MIDCOM superglobal alone was used over 5000 times in the OpenPSA code when the repository was created), some careful planning was required.

The other issue with $_MIDCOM was that, because it was so convenient to use, a lot of functionality was dropped there. Replacing them with an equally large class wouldn't have been much of an improvement, so a total of 29 functions was moved elsewhere and three were removed completely since they were unused. The remaining midcom_application class is still over 1000 lines long, but this step already improved maintainability noticably

The internal API change has been completed quite some time ago, but until recently, most of the code was still using the old $_MIDCOM access points via the midcom_compat_superglobal compatibility wrapper. That has all changed now, and since yesterday, it is possible to run OpenPSA with superglobals disabled.

If you have out-of-tree components you want to run on the o9 branch, you have two choices: You can either keep using the superglobals as long as the Midgard PHP extension supports them, or you can port your code over to the new API. For the most part, this is a simple matter of search and replace, but you can find more detailed information on the wiki.

Enjoy!