Ad hoc adapter classes 03

I’ve added a missing possibility to the original function calls collector adapter and planned the next steps on the path of ad-hoc adapter classes.

The problem

The basic idea of the project is to create a scalable way to “wrap” objects executing in the cosmos of WordPress globally defined functions and globals in adapter objects tailored on the application at hand.
I’ve approached the problem with “dictionary” adapters (run WordPress, dump all defined functions, create a wrapper for each) and walked the minimalistic way of magic __call method based adapters; the first approach added too much overhead in simply loading the adapter while the second will add runtime overhead and makes stubbing and mocking methods a chore. The middle ground is wrapping just the functions an object will call.
To do so an adapter collecting and dumping the functions calls will be used while developing with TDD methods to be swapped, maybe using a Dependency Injection Container, with the ad-hoc adapter in production code.
All this with as little overhead as possible during development.

A fix to a stupid error

I have pushed to GitHub a modified version of the FunctionsCallsCollector class to allow for stubbing and mocking of method calls in tests: that was obvious but I had forgotten it.

Next

I will be using reflection to decouple function call collection from generation and solve point 2 of this list.