RFC
| Q |
A |
| Proposed Version(s) |
4.0.0 |
| BC Break? |
Yes |
Goal
Removal of fluent interface for adapter options.
Background
Fluent interfaces are hard to read when working on code, especially if there is a bunch of setters being called since code-review (i.e. diff) usually does not provide context and at some point, the class the methods are called on, is not part of the diff anymore.
Even tho, I'd rather recommend passing all necessary options at once to the __construct of each adapter options class so that everything is set at once.
There is a good explanation on why fluent interfaces should not considered "required" in @Ocramius blog from 2013.
Considerations
I'd say there should be no need of setters at all. Options should be immutable, they're configured once and shouldn't get modified at runtime. If there is a need of having multiple caches with different options, its better to have dedicated cache configurations per per use-case. Parameters can be used to declutter duplicate config parameters.
Proposal(s)
I'd propose to make setters return void instead of being fluent. Users will have to migrate their code if they used setters to configure stuff.
Appendix
At some point, all options should be part of __construct where users can actually pass named arguments to have an instance of AdapterOptions available. AdapterOptions class should be removed at some point as well as there are just a bunch of shared options but having these repeated would be absolutely fine.
Instead, I'd say adapters should consume their options via __construct. Since we do have the PSR decorators which make use of the options, we will have to make adapters implementing PSR directly but that was already mentioned here.
RFC
Goal
Removal of fluent interface for adapter options.
Background
Fluent interfaces are hard to read when working on code, especially if there is a bunch of setters being called since code-review (i.e.
diff) usually does not provide context and at some point, the class the methods are called on, is not part of thediffanymore.Even tho, I'd rather recommend passing all necessary options at once to the
__constructof each adapter options class so that everything is set at once.There is a good explanation on why fluent interfaces should not considered "required" in @Ocramius blog from 2013.
Considerations
I'd say there should be no need of setters at all. Options should be immutable, they're configured once and shouldn't get modified at runtime. If there is a need of having multiple caches with different options, its better to have dedicated cache configurations per per use-case. Parameters can be used to declutter duplicate config parameters.
Proposal(s)
I'd propose to make setters return
voidinstead of being fluent. Users will have to migrate their code if they used setters to configure stuff.Appendix
At some point, all options should be part of
__constructwhere users can actually pass named arguments to have an instance ofAdapterOptionsavailable.AdapterOptionsclass should be removed at some point as well as there are just a bunch of shared options but having these repeated would be absolutely fine.Instead, I'd say adapters should consume their options via
__construct. Since we do have the PSR decorators which make use of the options, we will have to make adapters implementing PSR directly but that was already mentioned here.