3 ms·

The glorify globals thing is...a bit off. The real problem with global state is provenance, not the global state itself. Global state has the property of bein

The glorify globals thing is...a bit off. The real problem with global state is provenance, not the global state itself. Global state has the property of being identifiable, debuggable, and inspectable. Add provenance and you have a log from which you can see how your program executed and who did what. Local state isn't necessarily problematic but local mutable state can make some things really hard to track down / reproduce. "Subtle" bugs are bad. Things like modern games tend to are often developed with "local" data in the small being immutable and larger data being global (mutable is a coin-toss depending on how you're thinking about it).

taspeotis 13y ago
I think avoiding global variables is a good thing. Maybe at some large scale global variables are unavoidable but I've had good results wrapping what would otherwise be a global variable into a Context class and injecting IContext into everything that needs it. IContext is bound to Context with singleton lifetime in an inversion of control container. The benefit of this over actual global variables is that I can create as many IoC containers as I want and they can have their own "global" state. It's great if the application inside of the IoC container is solving part of a problem that's embarrassingly parallel - rather than creating 8 processes you create 8 threads and one container for each.
- logn 13y ago
  Shh. Don't tell the ineffective embedded devs about IoC containers or they'll be able to take their game to a whole new level. Dependency injection is great, but frameworks like Spring suck all the benefit out of it in my mind. Great, so I have a nice interface I can implement to re-use your module... except now I need to build a Spring app...
- coolsunglasses 13y ago
  IoC containers are useful when singletons are unacceptable, but even when I use IoC/DI I usually have a global "registry" somewhere for seeing who is "in-flight" and inspecting their state.

taspeotis 13y ago

I think avoiding global variables is a good thing. Maybe at some large scale global variables are unavoidable but I've had good results wrapping what would otherwise be a global variable into a Context class and injecting IContext into everything that needs it. IContext is bound to Context with singleton lifetime in an inversion of control container. The benefit of this over actual global variables is that I can create as many IoC containers as I want and they can have their own "global" state. It's great if the application inside of the IoC container is solving part of a problem that's embarrassingly parallel - rather than creating 8 processes you create 8 threads and one container for each.

logn 13y ago
Shh. Don't tell the ineffective embedded devs about IoC containers or they'll be able to take their game to a whole new level. Dependency injection is great, but frameworks like Spring suck all the benefit out of it in my mind. Great, so I have a nice interface I can implement to re-use your module... except now I need to build a Spring app...
coolsunglasses 13y ago
IoC containers are useful when singletons are unacceptable, but even when I use IoC/DI I usually have a global "registry" somewhere for seeing who is "in-flight" and inspecting their state.