As part of #2354475: [meta] Refactor the installer, (multi)site management, and pre-container bootstrap, we want to get rid of all or most of the singletons (, and a lot of the procedural code with global state).
We want to have regular objects that can be managed in the CoreContainer, and only keep static method access for BC.
One such singleton is \Drupal\Core\Site\Settings.
It is important for pre-container bootstrap, and we definitely want to make it a service in the CoreContainer.
The general strategy there is:
1. Split the singleton instance into a separate class, for a better separation of concerns.
2. Make it possible to freely instantiate it independently of the singleton instance variable (e.g. for unit tests).
3. Let the CoreContainer handle the (lazy) instantiation, and the dependencies needed for that.
4. Initialize the static instance variable with the instance from the container, for backwards compatibility.
Other issues to watch out for:
#2306013: Multisite is a valued feature that will not be deprecated.
#1757536: Move settings.php to /settings directory, fold sites.php into settings.php
Comments
Comment #1
donquixote CreditAttribution: donquixote commentedA current problem are the globals in Settings::initialize(), the $database variable, and the static call to Database::setMultipleConnectionInfo().
Having this call in the same method that includes the settings.php is a mix of concerns that should be separate.
I would like to turn all of these into local variables, which then become part of the return value.
Then there could be sth like $siteSettings->exportGlobals(), and $siteSettings->getDatabases().