Nathan B. wrote:
What’s the problem with global state? Rails itself is full of it and
it seems a bit impractical to have no global state, or more
appropriately, state that’s setup once per restart or some reload
event. What’s the alternative? Sure, one could follow the trivial
example you linked to in that railscast, but at some point, it gets
painful to have all your config being hash structures.
Of course there are times when global state is necessary (or useful). I
tried very hard not to say that it isn’t sometimes needed. There are
even times when singleton (or shared instances) are useful. What I’ve
been hinting at is that global state has been a crutch for a long time.
It’s probably one of the most overused, and misused, design patterns out
there. I was suggesting is that you think about whether you really,
absolutely, need that global state. There are no absolutes when it comes
to this stuff.
I just tend to think that if the “problem” you’re describing was a major
shortcoming of Rails then I would expect to hear lots of screaming from
lots of developers. AFAIK, I don’t think that’s happening.
I also tend to think that when I find myself fighting against a
framework that I know to be well designed, whether that be Rails or just
about anything else, I begin to look inward. I examine my own code and
my own understanding of the world as I see it to try and figure out why
I’m getting “push-back” from the framework.
I figure the chances of me using a wrong, or unexpected, approach to a
problem is likely far greater than a whole team of people (I know to be
smarter than me) making a glaring mistake. So rather than apply
additional pressure in attempt to drive my head though that brick wall I
built for myself, I instead take step back and search for a way to
remove the wall entirely.