Ad hoc adapter classes 02

In my previous post I’ve outlined my attempt at creating “smart” wrappers for objects relying on globally defined functions and stopped to remove two constraints: the first is gone.

The problem

A class willing to rely on an ad-hoc adapter object to abstract itself from globally defined functions and variables would have to inject an adapter object, if walking my path, implementing the tad_Adapters_FunctionsInterface interface.
I foresee scenarios for not doing this and came up with an ad-hoc (abusing the word here) “functions collector and adapter class” generator.
Injecting an adapter acting as an adapter while collecting all the called globally defined functions is part 1 of the two step process of custom adapter class generation I’ve outlined.


While still on the unit level (“unit” as “working but with limited usability”) I’ve added a class to the tdd-helpers package, FunctionCallsCollectorGenerator that will allow code like this:

(new FunctionCallsCollectorGenerator())
    ->setFileComment('Auto generated')
    ->setClassComment('Works as an adapter and dumps function calls.')

to generate a fully working adapter and collector class like:

 * Auto generated

namespace my\name\space;

 * Works as an adapter and dumps function calls.
class MyCollector implements ProjectWideAdapterInterface
    protected $called;
    protected $jsonFilePath;
    protected $shouldAppend;

    public function __construct()
        $this->called = array();
        $this->jsonFilePath = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'functions_dump' . time();
        $this->shouldAppend = false;

    public function __call($function, $arguments)
        $reflectionFunction = new \ReflectionFunction($function);


And that’s much more likely to make its way into a custom project.


I will be tackling the point 2 on the list.