-
Notifications
You must be signed in to change notification settings - Fork 6
Move plugins #70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move plugins #70
Conversation
|
||
/** | ||
* The client managing plugins and providing a decorator around HTTP Clients. | ||
* | ||
* @author Joel Wurtz <[email protected]> | ||
* | ||
* @deprecated since since version 1.1, and will be removed in 2.0. Use {@link \Http\Client\Common\PluginClient} instead. | ||
*/ | ||
final class PluginClient implements HttpClient, HttpAsyncClient |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we simply extend the base plugin client and add nothing? as the plugin interface extends the base plugin interface, everything should "just work". or is the base client final?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No we can't:
- The base client is final
- We would still have to do some hacks to throw the correct exception (in which case the exception is also final, so extension is not an option there)
looks good. and we actually should release that as 1.1 at some point. otherwise people that use stable deps will never see the deprecations in their code. we could also add the trigger_error code like symfony does, to see deprecation errors when enabled. https://knpuniversity.com/blog/upgrading-symfony-2.7 |
Ah, wanted to, but forgot it. |
9b63dd5
to
00012ab
Compare
Provide cross-compatibility between new and old plugins The deprecated PluginClient now wraps the new one internally and dispatches the requests to it. Full BC should be preserved, relevant exceptions caught and rethrown with the appropriate wrapping. Add deprecation error triggering
Merge and tag? |
👍 i let you tag if all is ready. |
Hm, what else to do? Only the separate packages are not tagged, everything else is. |
i think we should tag those (if they are ready to be tagged) before we tag this. when people discover they should move, the move target should be released and ready :-) |
Although there will be no version two, I added it so that in any case, we can continue using this package if necessary (like a metapackage installing all plugins, discussed elsewhere).
Also, please let me know what you think about the compatibility layer: