-
Notifications
You must be signed in to change notification settings - Fork 93
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
Don't use static methods #69
Comments
If I was feeling snarky I'd say it was because it was started by ruby programmers ;) I'm happy to look at ways we could make it less static dependent but for this major version we need to keep the API backwards compatible. |
Yeah, totally understand. I actually forked the lib and started looking at it, seeing how it could be done, but it's not gonna be that easy, as almost everything is static. |
I say go for it, it's the right approach. let's strive for backward compat but if not doable we'll rev the major version. |
Definitely. Also extremely handy for mocking in unit tests. |
1 year ago this question was posted - are there any plans on moving forward with refactoring? As it stands the library isn't that versatile. |
@dbergunder There will not be on the 2.x version of client. There's a lot of places that this code shows it age (lack of namespaces being the biggest). We've got some bigger changes to the API planned that will be require updated clients but there's no ETA on that. So one |
I know this is a stretch and would require some huge changes, but I'd like to address it none the less: Why does the client depend on static methods?
This highly limits the extensibility of the client. Want to write a Symfony2 bundle for it? Nope. Want to create a wrapper that sets the subdomain and apikey for you? Nope.
If major changes are ever considered, I'd highly suggest using an approach like
The text was updated successfully, but these errors were encountered: