I have a trivial Singleton class in my ‘lib’ folder, which has some
instance variables that I setup by calling a configure method from an
initializer. The initializer seems to execute just fine and sets up
the singleton instance. However, when I reference that same singleton
instance in a controller later, the instance variables are all nil, as
though the class was reloaded.
I’ve tried to do this in various forms using class variables, class
instance variables, but in every scenario, it seems the classes are
reloaded and all of the variables are nil.
Is there something special about how initializers run?
Environment -
Windows Vista
Ruby 1.8.6
Rails 2.3.4
WEBrick
-Nathan
Nathan B. wrote:
I have a trivial Singleton class in my ‘lib’ folder, which has some
instance variables that I setup by calling a configure method from an
initializer. The initializer seems to execute just fine and sets up
the singleton instance. However, when I reference that same singleton
instance in a controller later, the instance variables are all nil, as
though the class was reloaded.
http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial
Sorry, all I have to say about the subject.
On Sep 9, 4:10 pm, Robert W. [email protected]
wrote:
Sorry, all I have to say about the subject.
Any suggestions on an alternative approach? I’m open to do anything
that works.
My use case is an Authentication adapter library. I want to load the
configuration once and construct the configured adapter once and then
use it again and again.
I want something akin to how Rails/ActiveRecord configure database
adapter.
Thoughts?
Nathan B. wrote:
My use case is an Authentication adapter library. I want to load the
configuration once and construct the configured adapter once and then
use it again and again.
If I understand you correctly I think you’re looking for some like Ryan
Bates demonstrates here:
I’ve changed the subject, as I think I’m honing in on the issues I’m
running into – the loading semantics of files in the initializers
folder and files in the lib folder.
Is there anything to keep in mind when referencing classes in the lib
folder from an initializer? It seems like the files are loaded
multiple times, such that things like class variables and class
instance variables are re-initialized.
-Nathan
On Sep 10, 12:44 am, Robert W. [email protected]
wrote:
Nathan B. wrote:
My use case is an Authentication adapter library. I want to load the
configuration once and construct the configured adapter once and then
use it again and again.
If I understand you correctly I think you’re looking for some like Ryan
Bates demonstrates here:
#85 YAML Configuration File - RailsCasts
Thanks for the tip.
Nathan B. wrote:
I think I’ve figured out the issue. The problem seems to be that in
development, the class caching was disabled by default, so the classes
were reloaded on every request, but the initializers aren’t re-run,
which is can be rather painful.
Yes, I would expect that class caching is disabled in development. It
would certainly be painful if it wasn’t disabled. As I understand it the
disabling of the caching is done to support rapid turnaround. See a
problem, fix the code, refresh the page and see the fix. This should not
normally be a problem as long as you don’t rely on global state, which I
think is good practice anyway.
On Sep 10, 2:16 pm, Robert W. [email protected]
wrote:
normally be a problem as long as you don’t rely on global state, which I
think is good practice anyway.
I meant, it can be rather painful to work in development mode with all
of you the classes getting reloaded EXCEPT for the initializers. That
can create some rather unpredictable behavior.
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.
On Sep 10, 1:01 am, Nathan B. [email protected] wrote:
I’ve changed the subject, as I think I’m honing in on the issues I’m
running into – the loading semantics of files in the initializers
folder and files in the lib folder.
Is there anything to keep in mind when referencing classes in the lib
folder from an initializer? It seems like the files are loaded
multiple times, such that things like class variables and class
instance variables are re-initialized.
I think I’ve figured out the issue. The problem seems to be that in
development, the class caching was disabled by default, so the classes
were reloaded on every request, but the initializers aren’t re-run,
which is can be rather painful.
-Nathan
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.