Skip to main content ↑ ↓
Topic: $modSettings (Read 2612 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

$modSettings

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
Code: [Select]
<?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.

Re: $modSettings

Reply #1 –

Just for reference, there is a class ValuesContainer implements \ArrayAccess that may be a base for that. O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: $modSettings

Reply #2 –

Quoteit shouldn't really break anything
  we need to tm that :D

But yeah, its a throwback that needs to be addressed, I like what you have outlined.

Re: $modSettings

Reply #3 –

Quote from: emanuele – Just for reference, there is a class ValuesContainer implements \ArrayAccess that may be a base for that. O:-)
Perfect

Quote from: Spuds –
Quoteit shouldn't really break anything
  we need to tm that :D

But yeah, its a throwback that needs to be addressed, I like what you have outlined.
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:
Code: [Select]
<?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)
	{
		
	}
}

Re: $modSettings

Reply #5 –

What will change everything for Addon developers. Will there without IT Studied then be possible to develop Addons?
Regards Stephan

Re: $modSettings

Reply #6 –

Quote from: Joshua Dickerson – and then it shouldn't really break anything.
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).
Bugs creator.
Features destroyer.
Template killer.