Rails - Sep 2009 - Singleton class setup in initializer, but seemingly reloaded later

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 Beyer 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.
-- 
Posted via http://www.ruby-forum.com/.

On Sep 9, 4:10 pm, Robert Walker
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Nathan Beyer 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/WhySingletons...
>
> 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 Beyer 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:

http://railscasts.com/episodes/85-yaml-configuration-file
-- 
Posted via http://www.ruby-forum.com/.

On Sep 10, 12:44 am, Robert Walker
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Nathan Beyer 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:
>
> http://railscasts.com/episodes/85-yaml-configuration-file
Thanks for the tip.

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 9, 3:40 pm, Nathan Beyer
<nbe...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
>
> 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

On Sep 10, 1:01 am, Nathan Beyer
<nbe...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
>
> On Sep 9, 3:40 pm, Nathan Beyer
<nbe...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
>
> > 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 Beyer 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.
-- 
Posted via http://www.ruby-forum.com/.

On Sep 10, 2:16 pm, Robert Walker
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Nathan Beyer 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.
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.
> --
> Posted viahttp://www.ruby-forum.com/.

Nathan Beyer 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.
-- 
Posted via http://www.ruby-forum.com/.