README

A container class for settings objects - decouple configuration logic from your application! Not a DI container.

• SettingsContainerInterface provides fancy property hooks for PHP < 8.4.

Documentation

Installation

requires composer

composer.json (note: replace dev-main with a version constraint, e.g. ^3.0 - see releases for valid versions)

{
	"require": {
		"php": "^8.1",
		"chillerlan/php-settings-container": "dev-main"
	}
}

Profit!

Usage

The SettingsContainerInterface (wrapped inSettingsContainerAbstract) provides plug-in functionality for immutable object properties and adds some fancy, like loading/saving JSON, arrays etc. It takes an iterable as the only constructor argument and calls a method with the trait's name on invocation (MyTrait::MyTrait()) for each used trait.

A PHPStan ruleset to exclude errors generated by accessing magic properties on SettingsContainerInterface can be found in rules-magic-access.neon.

Simple usage

class MyContainer extends SettingsContainerAbstract{
	protected string $foo;
	protected string $bar;
}

// use it just like a \stdClass (except the properties are fixed)
$container = new MyContainer;
$container->foo = 'what';
$container->bar = 'foo';

// which is equivalent to
$container = new MyContainer(['bar' => 'foo', 'foo' => 'what']);
// ...or try
$container->fromJSON('{"foo": "what", "bar": "foo"}');


// fetch all properties as array
$container->toArray(); // -> ['foo' => 'what', 'bar' => 'foo']
// or JSON
$container->toJSON(); // -> {"foo": "what", "bar": "foo"}
// JSON via JsonSerializable
$json = json_encode($container); // -> {"foo": "what", "bar": "foo"}

By default, non-existing properties will be ignored and return null:

$container->nope = 'what';

var_dump($container->nope); // -> null

You can change this behaviour by adding the attribute ThrowOnInvalidProperty to your container class:

#[ThrowOnInvalidProperty(true)]
class MyContainer extends SettingsContainerAbstract{
	// ...
}

$container->nope = 'what'; // -> throws: attempt to write invalid property: "$nope"

Advanced usage

Suppose the following trait from library 1:

trait SomeOptions{
	protected string $foo;
	protected string $what;

	// this method will be called in SettingsContainerAbstract::construct()
	// after the properties have been set
	protected function SomeOptions():void{
		// just some constructor stuff...
		$this->foo = strtoupper($this->foo);
	}

	/*
	 * special prefixed magic setters & getters ("set_"/"get_" + property name)
	 */

	// this method will be called from __set() when property $what is set
	protected function set_what(string $value):void{
		$this->what = md5($value);
	}

	// this method is called on __get() for the property $what
	protected function get_what():string{
		return 'hash: '.$this->what;
	}
}

And another trait from library 2:

trait MoreOptions{
	protected string $bar = 'whatever'; // provide default values
}

We can now plug the several library options together to a single class/object:

$commonOptions = [
	// SomeOptions
	'foo' => 'whatever',
	// MoreOptions
	'bar' => 'nothing',
];

$container = new class ($commonOptions) extends SettingsContainerAbstract{
	use SomeOptions, MoreOptions;
};

var_dump($container->foo); // -> WHATEVER (constructor ran strtoupper on the value)
var_dump($container->bar); // -> nothing

$container->what = 'some value';
var_dump($container->what); // -> hash: 5946210c9e93ae37891dfe96c3e39614 (custom getter added "hash: ")

A note on property hooks (PHP 8.4+)

Property hooks are called whenever a property is accessed (except from within the hook itself of course), which means that the custom get/set methods this library allows would conflict when a custom method is defined for a property that also has a hook defined. To prevent double method calls, the internal methods hasSetHook() and hasGetHook() have been introduced, and are called whenever the magic get/set methods are called: when both, a custom method and a property hook exist, only the property hook will be called.
Public properties will never call the magic get/set, however, their hooks will be called. (un)serializing a SettingsContainerInterface instance will bypass magic get/set and existing property hooks, while JSON de/encode as will call magic get/set or existing hooks explicitly via the toArray() and fromIterable() methods.

class PropertyHooksContainer extends SettingsContainerAbstract{

	protected string $someValue{
		set => doStuff($value);
	}

	// this method will be ignored in magic calls as a "set" hook on the property exists
	protected function set_someValue(string $value):void{
		$this->someValue = doOtherStuff($value);
	}

	// this custom method will be called as the property has no "get" hook
	protected function get_someValue():string{
		return doWhatever($this->someValue);
	}

	// this property will never trigger the magic get/set and associated methods
	public string $otherValue{
		set => doStuff($value);
		get => $this->otherValue;
	}

}

API

SettingsContainerAbstract

Internal (protected) methods

Disclaimer

This might be either an absolutely brilliant or completely stupid idea - you decide (in hindsight it was a great idea I guess - property hooks made their way into PHP 8.4).
Also, this is not a dependency injection container. Stop using DI containers FFS.