@hansschuijff

1 year ago

Hi Gio, I was thinking about the Config class and the fact that there are now lots of config files. The why of making a class to basically wrap just one of the config files. My guess is that it is only for the DI, not really for config as general, but it may lead to some confusion too, since now most config files are just required or included, but one file is called Config in the app and has it's own class. In my own procedural programming for WordPress, I tended to use a get_config function that received a key and returned some data derived from config files. Basically a similar idea, but implemented for all config files together, and implementing a static cache in it too since I thought that might be more efficient than loading a file whenever I needed a key value. For the path info I used something similar called get_plugin_data() that was basically a wrapper around the same function in WordPress, but added the plugin paths to it. So in the end I had a single entry point for config and another for plugin meta data, like the descriptions and paths. Perhaps a bit comparable with a model abstraction layer. I understand there are different solutions possible and wonder what your thoughts are about one entrypoint for loading all config files, versus the current solution.

|