If you have need to play sound in the depths of physics code, global access to sound resources doesn't endanger modularity any more than explicitly passing the resources. In both cases you need to #include sound code in your physics code, which should be enough of a red flag.

infact there are better solutions. Your physics subsystem could just expose an "onCollision" event with subscribers and the connection between audio and physics is then handled much higher in the code thus maintaining total modularity and independence.

The point is that making everything global like a big lump of memory makes things very comfortable because, basically, you need no design at all... but that is not how you create maintainable clean software, that way you just hack away. That might be perfectly fine for small software projects but it's a recipe for disaster for bigger projects.

infact there are better solutions.

Oh, you misunderstood what I said. I didn't advocate design where physics code has dependencies to audio code, but that having global access to resources doesn't hide such a dependency any more than explicitly passing the resources to the code. It means that some physics programmer doesn't accidentally write dependencies to audio code because of global resources, but that he needs to also access audio API's anyway thus is well aware of making such a dependency. And you are absolutely right that such a connection between the engine sub-systems should be made at a higher level.

I think global resources have their proper uses, but you need to weigh pros vs cons to see if they are the best solution for given problem. No one is saying you should make everything global ;)

The point is that passing parameters takes effort, so makes you stop and think. Using a global is too easy.

I wasn't suggesting that a pointer to an audio subsystem was passed as a parameter into the physics code. I was suggesting that if I stopped and thought about it, I'd probably think of a way of achieving what I wanted with less dependency.

We live in the real world. We get tired, pressured, out of time and so on. One of the biggest reasons for the development of good software design methodology is to combat these human traits in all of us.

Sure, I can say now that I'll use that global carefully and not allow it to propagate dependancies all over the code base. But in six months time, when my boss has just screamed at me about something unjustified and I'm angry and want to leave but can't shut the computer down until I've finished some god-awful feature that I never thought should be implemented in the first place...

These are human realities of programming.

... but that having global access to resources doesn't hide such a dependency any more than explicitly passing the resources to the code. It means that some physics programmer doesn't accidentally write dependencies to audio code because of global resources, but that he needs to also access audio API's anyway thus is well aware of making such a dependency.

[/quote]

I beg to differ. Sure, the person who wrote the code would be aware of the dependency, but the next person might be in for a surprise when they go to write a unit test for the physics code and the loud grunt of the Zlorb enemy species taking damage or the orgasmic death throes of the femme fatale are triggered in rapid succession... or both!

A global is about as hidden as a dependency can reasonably get.