mark classes as final and methods and properties as private #123
Conversation
|
ignore styleci here. we switched to pretty-ci, i disabled styleci for this repository now. |
|
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. @php-http/owners wdyt? @sagikazarmark and if you agree to make the clients final, can you check if its sane what i did with php spec? |
|
I agree with @gmponos. If we should be really correct, we should use an interface for all classes we mark as final. Interfaces could be added after 2.0.0 though. But (of course) we cannot add final. |
|
TBH I don't really like the |
|
We could use the |
|
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. |
dbu
force-pushed
the
mark-as-final
branch
2 times, most recently
from
67a7b24 to
86b2d1a
Compare
It's the exact opposite of having My point of view is that I would prefer to be inconsistent with interfaces and some to have the |
|
for php-http we decided to avoid the interface suffix. we could add it for those cases - it would also make the upgrade path a bit different, because there would be no BC break at all. instead, the user should change all of their code to typehint interface instead, but things work fine without, unless they want to test with mocks. unless i hear any other arguments, i will go with the Interface suffix for these and chose ease of upgrade over consistency. |
|
I would also probably go with the interface suffix with a big fat warning, that otherwise that's a ten kittens offense |
We add interfaces for final classes so that they can be mocked in testing. We chose to use the Interface suffix here to avoid name clashes, rather than renaming the existing PHP classes. The interfaces are only relevant for unit testing, we do not expect people to provide their own implementations. HttpClientPoolItem is purely internal and we therefore don't want an interface for it. It is marked with @Final and explained to not be meant to extend.
|
okay, i changed to the interface suffix and like the changes and its impact a lot more! want to merge @sagikazarmark ? |
|
php-http/HttplugBundle#291 and php-http/documentation#244 also become much simpler this way \o/ |
|
Sorry, looks good to me. 👍 |
What's in this PR?
Mark the remaining things final.
Why?
See #20
Checklist