I don't know if this might be needed, but I've added a Config class to the project that can be passed instead of an array when initializing some of the library's objects. This offers several advantages over using an array as a configuration format:
Users can immediately see which options are available without needing to consult the documentation.
All options are type-checked (either by the IDE or PHPStan).
The class reduces the likelihood of incorrectly typing an option's name.
If options are added or renamed in future updates, static analyzers will flag these changes.
Originally, I had planned to change the internal config variable used by all classes in this library to the Config class, but this could cause a breaking change due to the getConfig($key) method (since some users might use arrays for more options than this library provides). For now, this PR doesn't alter any existing behavior and simply adds the option of passing configuration values as a Config instance. If you like this change I could alter the code to use this class instead of array in the future (of course this change can still support passing the config as an array).
Hello,
I don't know if this might be needed, but I've added a Config class to the project that can be passed instead of an array when initializing some of the library's objects. This offers several advantages over using an array as a configuration format:
Originally, I had planned to change the internal config variable used by all classes in this library to the Config class, but this could cause a breaking change due to the
getConfig($key)
method (since some users might use arrays for more options than this library provides). For now, this PR doesn't alter any existing behavior and simply adds the option of passing configuration values as a Config instance. If you like this change I could alter the code to use this class instead of array in the future (of course this change can still support passing the config as an array).