On Nov 9, 3:00 pm, Tom Lea <[EMAIL PROTECTED]> wrote: > The key here is that they do behave as expected in production. There > is nothing inherently wrong about keeping instances between requests.
Agreed -- this works fine in production. The issues we're discussing are only occur when config.cache_classes = true (i.e., development.) > If this is indeed the aim, should the same logic apply to instances of > other classes? > > I fear this is a bridge too far. You do make a good point about this being an issue with non-AR classes, if they're reloaded -- if we're discussing neutering zombie AR classes, perhaps we should really be discussing neutering any class that's reloaded via Dependencies. As it stands now, for any class (AR or otherwise) that is reloaded, any instances that were created prior to reloading won't respond to #== and #is_a? as expected. Seems like the choice here is between: 1. accepting the possibility of weird, buggy, hard-to-diagnose behavior in development (in which case, we could then consider your patch, which solves some, but not all, of the issues we've identified), and 2. prohibiting the user from using instances of reloaded classes that persist between requests in development, thereby requiring the user to work around this in their application code Not a great set of choices, I know. Am I missing something here? Thoughts? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
