> We can ease the pain of running such code in development by not > reloading all classes after each request. But reloading only changed > classes or reloading all classes if something has changed. There were a > plugin which tried to reload only changed clasess. It didn't work for > us. So I created (and haven't published yet) a simpler solution which > reloads everything only if anything has changed. We can put this code > into rails.
This sounds like a good idea, but inter-dependent modules and the like could get a little confusing / tricky. Sounds like a good addition to 2.3. We already do this for routes.rb, but it's a much simpler case to handle > Also we can ease development pain for such cases by restaring whole > process instead of reloading classes. CGI should work fine here for > example. Doing it other way seems non-trivial, because new process will > need to inherit connected socked from old process but nothing else. We had CGI based development back before 1.0, it was much slower, and much more frustrating. It would take a lot more than this one case to justify switching. The memory store could also be replaced / complemented with a 'marshaling memory store' which would completely work around this problem. -- Cheers, Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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-core?hl=en -~----------~----~----~----~------~----~------~--~---
