Closed phux closed 7 years ago
I am not sure if I understand you:
You don't want to open the class to inheritance because then the maintenance gets more complex because of the possibility of breaking existing functionality users could depend on?
Decreasing the amount of reusability for easier maintenance isn't the right approach. It makes sense to provide the functionality to people that maybe can't contribute code clean & abstract enough for this repo.
The newly protected functions would have to be duplicated and that's not an option IMO :)
Inheritance is not the best mechanism for adding functionality, but it's the easiest in this case. Given that WebApiContext doesn't have any other extension points, we can only inherit it to extend. But that is pretty useless, because most interesting properties are private: $client, $headers, $request, $response. So, even if you inherit, you can't do anything with request or response :)
In my case, I have to add additional checks for response content, so I have no other choice but to switch to one of the forks, which already exposed properties to the class' protected interface.
I believe though that the better solution would be to make it possible to add 'When' and 'Then' by composition. For example by adding handlers for Request and Response into WebApiContext through tags on DependencyInjection.
I really need this change :+1:
Making things protected means they become extension points for which BC needs to be maintained. Opening everything is not the right approach IMO.