Since a new StorageDispatcher object for which we don't have a clear purpose was introduced in this issue,
- Removing it completely, everything still runs, best proof of that it is not needed at this point, and the code looks much cleaner.
- Simplify building Config objects, since they always need a name, the name should be in the constructor, this one looks quite obvious to me since code is cleaner and saves a few lines.
This should also improve performance and lower memory usage, though I don't have any benchmark, it should be obvious that by creating a Database storage once and reusing it for all the request's config objects, we are saving some logic and a few objects to be created.
That unless we come up with a clear purpose and/or some use for that StorageDispatcher thing, which is not happening atm, see
The whole point is: if all our use cases can be rewritten without it and still simplifying the code, why is it there?
In addition to that it is making other intents of plugging into the config system more complex, like
PASSED: [[SimpleTest]]: [MySQL] 39,896 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch config.dispatcher.32.patch. Unable to apply patch. See the log in the details link for more information. View
|#25||config-1671080-24.patch||11.72 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [MySQL] 39,904 pass(es). View
|#21||config-1671080-21.patch||11.71 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View