Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
mark classes as final and methods and properties as private #123
What's in this PR?
Mark the remaining things final.
I know that you want to enforce composition instead of inheritance but in real life scenarios there are cases that you will need to depend on implementation instead of abstraction.
This way it will make mocking impossible. Especially when clients like
Don't get me wrong I am all in for final but not for packages like this. If it was like guzzle having only one implementation I think it would make sense. But for packages like this one that contain multiple implementations of the same abstraction I think it's not the best thing to do...
For instance take a look at this.. it has no finals. Although I can't be sure if this was made on purpose. The point is that there will be real life scenarios that I will need to depend specifically in
That's my opinion for what is worth it.
hm, i see what you mean, and with the utility clients like batch or method client, you are certainly right. but i think we still want to prevent people from extending the specific clients. our options are:
i think i prefer the second option, as that is cleaner.
@sagikazarmark and if you agree to make the clients final, can you check if its sane what i did with php spec?
i added the interfaces. i opted to change the classes to
i think the interfaces are a clean thing here and we want them. if somebody has a better idea for the naming, i am happy to change it, but i don't know one. we could have a subnamespace for the implementations, but that does not seem better :-)
if the other @php-http/owners agree, i will do a pull request on the documentation as well.