As a companion to this, how about we look into a service locator / dependency injection model to eradicate globals? Granted, using such a thing is a thinly-veiled global (just a static / singleton object that houses all the shared items we need) but it does have a few material benefits over globals:

Less pollution of global scope.
Easy to extend if we need more shared items; all shared resources are in one place.
Easier to replace implementations if a better method arises (as long as method signatures stay the same, via an adapter / interface).
Decoupled, so easy to stub for unit testing, with more structured tests possible.
Lazy loading of shared items, potentially saving resources.
Plugins can utilise it to share their own resources across Textpattern.

Effectively, it's a very simple class with two methods: set() to register a class/object/closure and get() to retrieve / execute it. Client code just embeds the service object, calls get() and then has access to the resource, which could either be a new instance or a static resource depending on how it was registered.

Good candidates for this treatment might be the $DB, $prefs, config variables / $pretext, and so forth.

Here's a starter class, which can no doubt be improved (heck, we could even add a callback!) :

namespace Textpattern\Service;

class Registry
{
    protected $services = array();

    /**
     * Register a service. Chainable.
     *
     * @param string $name   Service name
     * @param mixed  $def    Closure or class name
     * @param bool   $shared Whether this resource is a shared instance
     */
    public function set($name, $def, $shared = false)
    {
        $this->services[$name] = array($def, $shared);

        return $this;
    }

    /**
     * Resolve a service.
     *
     * @param  $name Service to fetch
     * @return mixed
     */
    public function get($name)
    {
        if (array_key_exists($name, $this->services)) {
            $arr = &$this->services[$name];

            if (is_callable($arr[0])) {
                $obj = call_user_func($arr[0]);
            } elseif (is_string($arr[0])) {
                $obj = new $arr[0];
            } elseif (is_object($arr[0])) {
                $obj = $arr[0];
            }

            if (isset($obj)) {
                return ($arr[1] ? $arr[0] = $obj : $obj);
            }
        }

        // @todo Trigger error.
    }
}

To use it to store the prefs, for example, register the prefs in index.php where we'd normally extract() them:

Txp::get('\Textpattern\Service\Registry')->set('globalPrefs', function () {
   static $prefs = null;
    if ($prefs === null) {
       $prefs = get_prefs();
   }
    return $prefs;
}, true);

then alter get_pref() to first load in the prefs and return the key of interest:

function get_pref($thing, $default = '', $from_db = false)
{
    $prefs = Txp::get('\Textpattern\Service\Registry')->get('globalPrefs');
    ...
}

Finally, change all global $prefs[] references to get_pref() calls, as Ruud originally suggested.

Is it overkill or does this sort of model have merit for sharing resources in code?

Uh oh!

$prefs and $pretext are extracted globally #545

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions