On Sep 10, 2:16 pm, Robert Walker <[email protected]>
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/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
