Ad hoc adapter classes 01

2-minute read

I’ve laid the base for the process of collecting calls to globally defined functions and moved from magic method based to ad-hoc generated adapter classes.

Refactoring

I’ve not added much function to the code beside the one I’ve presented in the previous post and dedicated some time to refactoring and general code polishing.
I’ve dropped sprintf based templating to move to Smarty and improved overall code maintainability and reuse possibilities. Simplification and extraction broke down the code complexity and allowed me to re-use some parts and make new ideas flourish.

Actual constraints

The ad-hoc adapter class generation is now based on using an adapter logging the called functions during normal tests, FunctionsCallCollector, and then feeding its .json file output as input to the AdapterClassGenerator which will then generate ad-hoc adapters.
Two possible weaknesses come to my mind:

  1. mandatory injection of a tad_Adapters_FunctionsInterface implementing object - the FunctionCallsCollector extends what I use but avoiding that constraint and adding the possibility of ad-hoc functions calls collector generation would be nice; I’m not thinking everyone will want to depend on the same adapter I wrote.
  2. synchronisms - while it’s useful, and my use case, generating the ad-hoc adapter class is generated while the tests run this means that the adapter class generator must be able to use reflection on the functions defined in the global space at that moment. In a WordPress context this means that a whole, although headless, WordPress session must be up and running or reflection will fail.

Next: possible solutions

While point 1 above will be easy to resolve point 2 might require some more specific solution that I will explore and that will start from the context I work in: the WordPress one.

In the meanwhile peeks available

I’ve pushed, and will keep pushing, the develop branch to GitHub to allow peeking the work in progress.