-
Notifications
You must be signed in to change notification settings - Fork 286
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
Kill a lot of the globals #306
Comments
I actually want to rename this to "let's try to get rid of as many globals as possible". Having gone through the code with the module rewrite PR, there's a lot of places where what I would expect to happen will not happen. |
I did a quick search, this is a rough list of the globals I think should be killed in theory:
|
I think in general, I'd like to be able to have two independent |
I agree with the general sentiment of removing the globals, but sometimes they are necessary to provide hook points for private implementations. We use that in several places like, for instance, the metrics backend comes from a closed source repo. |
+1 for Glib, there are useful in some cases to make code more easy and intuitive to use. We can go after specific globals that kill thread safety or make testability harder etc., not all of them. |
@glibsm can you be more specific here? AFAICT, using dependency injection to accomplish polymorphism (what I think you're talking about here) is more obvious for users and better for testing and concurrency. You no longer need to wonder what globals exist or what side-effects occur, since everything is explicit and defined at the func/struct level. At face value, I agree with @peter-edge here - it would be great if the user experience for UberFX was:
In general, we've pushed really hard not to have any globals in YARPC, since they compose very poorly, make testing harder, and introduce problems with concurrency. |
@breerly e.g. RPCInit Dispatcher is different from YARPC Dispatcher, this could go away with DI though. |
@breerly Take a look, for instance, at I agree that DI can probably help with this, or completely replace the practice alltogether, but we're nowhere near ready to start replacing these registration functions with dig, which is still in short trousers. |
100% agreed - let's grow into it, with the goal of using DI and dig to accomplish this 🗡 |
#323 gets rid of the relevant global variables in the metrics package. |
Closing - the |
I ran into a testing bug where I was scoping all metrics for a given module to
host.Metrics().SubScope("modules").SubScope(moduleName)
, which I think is desired (if I have two http modules, I would prefer to have stats on them separately). I found out this breaks the flow completely - I think it would be nice to take out the globals in theinternal/stats
packages, and setup any middleware etc to use a wrapping interface that exposes the metrics we care about.The text was updated successfully, but these errors were encountered: