It's always been one of my least favorite things in SMF. First off, it is a throwback to settings which mods added. When all of the forum's settings were in a file but mods could add settings to the database. So, the name is stupid.
I have always loved how we program to assume the setting doesn't exist, but it does add a lot of code that just checks if the key exists.
Every key from the database gets loaded. That's kind of a waste of a table which could be a simple key/value store. Settings should be immutable in the instance. If you want to change something, you should use another variable.
So, first off, I want to change $modSettings (and every usage of it) to be $elk['settings']. Since we don't have a DIC, $elk will just be an array. It will point to an instance of ElkArte\Settings.
The 30 second mockup
<?php
namespace ElkArte;
class Settings
{
protected $settings;
// @see reloadSettings()
public function reload()
{
}
public function __get($name)
{
return isset($this->settings[$name) ? $this->settings[$name] : null;
}
public function __isset($name)
{
return isset($this->settings[$name]);
}
protected function loadFromDatabase()
{
}
protected function loadFromCache()
{
}
}
Stop gap solution is to use $modSettings and $elk['settings'] at the same time. We can add a getAll() method which will return $settings and then it shouldn't really break anything.
Just for reference, there is a class ValuesContainer implements \ArrayAccess that may be a base for that. O:-)
we need to
tm that :D
But yeah, its a throwback that needs to be addressed, I like what you have outlined.
Perfect
Hahaha, yeah.
So... does that mean I can change settings table to be a key/value store in 1.1? Adding a new column "loadgroup" being a tinyint and 0 being the autoload group. Maybe change the name to kv_store? Then I will put the registration agreement in there with "agreement_english". I will write up some documentation saying to be careful with loading things by their group. You should check to make sure the key is what you want.
Then that class would look more like:
<?php
namespace ElkArte;
class Settings extends ValuesContainer
{
protected $group_keys = array(0);
// @see reloadSettings()
public function reload()
{
}
public function isAutoloaded($key)
{
return isset($this->group_keys[0][$key]);
}
public function getByGroup($group)
{
$group = (int) $group;
if (!isset($this->group_keys[$group]))
{
$this->loadFromCache($group);
}
$return = array();
foreach ($group_keys[$group] as $key)
{
$return[$key] = $this->data[$key];
}
return $return;
}
protected function loadFromDatabase($group = 0)
{
}
protected function loadFromCache($group = 0)
{
}
}
That which is old is new again: http://www.elkarte.net/community/index.php?topic=2581.0
What will change everything for Addon developers. Will there without IT Studied then be possible to develop Addons?
I missed that. LOL
I'm not so sure it will not break anything.
To be honest, at some point I thought about simply wrapping $modSettings into a ValuesContainer, but than I gave up because I'm pretty sure this will break some stuff (mainly because of += used in some places).