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
Well, I guess you mean asking why Rails::Application is a singleton class rather than Rails.application being a singleton object. I'm curious, why is it relevant whether Rails::Application is a singleton class or not? Rails.application should always return the same object regardless, right? Also, I'm curious, why is this related to that talk (I've watched it yesterday in full and I can't find how it's a related subject)?
Do you have any use case where you'd want to instantiate Rails::Application that would be better than inherit a new class?
I'm not saying that a singleton class is the best approach for Rails::Application, but I can't see any disadvantage for it either. That's why I'm asking. If you have some use case where you'd think the singleton class is a problem please let us know.
Just thinking about object allocation made me think of the Rails singleton, though I admit the implication of my association is that there would be a case where one would want multiple instance of a Rails object, which is not a case I have thought about.
I also just think of the Singleton pattern as a kind of strange as it’s not far removed from being a utility function class. To wit, we call Rails::Application.initialize! but why does that need to fire once on the ‘singleton’ instance rather that on the class, since class instance variables are a thing. And now that Rails.application behaves very much like Rails::Application’s subclass, the distinction is decreasing.
(Thanks for your response, so for delay as I somehow didn’t see it)
As I see this, even if it’s possible to remove the singleton pattern
for this class (I don’t know if there’s some specific reason for it
to be a singleton) I’d ask: why should it be changed? If it’s just
for code styling, then let the Rails core team decide how they
prefer the code to be written/read.
Now, if you really think you’d have a valid use case for creating
multiple instances of Rails::Application where inheriting a new
class from it would be less than ideal, then exposing such use case
could certainly trigger a discussion upon removing the Singleton
pattern from it. Otherwise I don’t think we should argue about code
styling in the rails core mailing list as it could easily take all
discussion over here about code styling