11–20 of 165 posts
Please no. Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.
Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?
Singleton is a pattern to ensure that a global objects is only ever initialized once.
Please no. Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.
Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?
Earlier quoted context omitted.
Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?
You know it is /currently/ accessed on one thread. These are little landmines that add up over time.
The conclusion of your argument looks like 2000s Java - throw a mutex on every property because you never know when it will need to be accessed on a thread.
Designs that spread complexity rather than encapsulate it are rarely a good idea.
I agree with this, but the problem with global variables is precisely that they make bad data access patterns look easy and natural. Speaking from experience, it’s a lot easier to enforce a “no global variables” rule than explain to a new graduate why you won’t allow them to assign a variable in module X even though it’s OK in module Y.
Earlier quoted context omitted.
Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?
how do you know that? just about every serious bug i have ever written was when i thought i understood multi-threaded code, but didn't.
> when i thought i understood multi-threaded code, but didn't.
All the more reason to carefully plan and limit shared state among threads. It's hard enough to get right when you know where the problems are and impossible if you spray and pray with mutexes.
I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages.
Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation.
I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
Hard disagree. If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages. Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing…
I mean yes, using global variables is just one of the ways to cause action-at-a-distance and that is... apparently a big reveal?
Otherwise sure, there is no pattern that cannot be utilized 100% correctly and without introducing bugs. Theoretically. Now let's look at the practical aspects and how often indiscriminately using such tempting patterns like global variables -- and mutexes-when-we-are-not-sure and I-will-remember-not-to-mutate-through-this-pointer -- lead to bugs down the road.
The answer is: fairly often.
IMO the article would be better titled as "There is no pattern that a lazy or careless programmer cannot use to introduce a bug".