I was interested to see why Rails.application etc. is a singleton object, as I was curious about the use-case for this somewhat strange design-pattern in a dynamic language like Ruby-- the object encapsulates state, but that state is global, so is it really state?...
I looked into the Rails source from master back through 3.0, and was surprised to see that even though there is an instance method that caches the new object, and :new is made private (per the pattern), the singleton library itself is not used... and yet it is used elsewhere in the codebase. I think this is work that Yehuda, Carl, and José mostly did in 3.0 that has mostly been shuffled around a bit. Its origins appear to be the change from every Rails app having a Rails::Application to everyone subclassing Rails::Application and it then becoming 'illegal' to directly instantiate a Rails::Application.. and yet.. Anyone have any insights into this? Or should I ask on stackoverflow? :) My initial impetus for looking into it, just now, though I'd been thinking about it occasionally, was Aaron's recent talk at BigDot Ruby on benchmarking performance, which got me thinking about object allocation and the Rails singleton. https://www.youtube.com/watch?v=d2QdITRRMHg -Benjamin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
