All __construct() methods in Solar have exactly one parameter: an
associative array. That array is then populated into the protected $_config
property used in all classes descended from the Solar base class.
Most classes in the PHP world use a sequential set of parameters for constructors; e.g., if you wanted to specify three pieces of information for a constructor, you would do something like this:
<?php
class Normal_Example {
public $a = null;
public $b = null;
public $c = null;
public function __construct($a, $b, $c)
{
$this->a = $a;
$this->b = $b;
$this->c = $c;
}
}
$example = new Normal_Example('one', 'two', 'three')
?>
In comparison, Solar classes can be instantiated like this:
<?php
class Solar_Example extends Solar_Base {
// note that the config property is named for the class
// with an underscore prefix. this lets us collect the
// parent config defaults as well.
protected $_Solar_Example = array(
'a' => null,
'b' => null,
'c' => null,
);
}
$config = array(
'a' => 'one',
'b' => 'two',
'c' => 'three'
);
$example = new Solar_Example($config);
?>
Note: Usually Solar objects are instantiated via Solar::factory(), not via direct instantiation as above, but you get the idea.
Why do things this way? The idea is to make it easy to read data from a config file and automatically configure object instances.
In the Solar_Example class, the constructor parameter could easily be read from a configuration file and passed to the Solar_Example constructor, which is not so easy with the Normal_Example.