I've been thinking about this and I am not totally convinced by the
configuration use case. Let me explain.
A callback would technically allow that kind of class configuration idiom,
but let's for a moment imagine the initializer (writing on an iPad):
# config/initializers/invoice_configuration.rb
ActiveSupport::Dependencies.on_autoload('Invoice') do
Invoice.configure do
self.generator = MagicPDF
end
end
Looks too convoluted to me for the trivial task that configuring a class
should be. Also it looks kinda unbalanced to me, there's that framework
level instruction that to me looks out of place intuitively.
Think about the maintainer, what on earth is this code? The code comment to
explain that idiom would be longer than the code itself. Smellish.
Also, the maintainer would wonder, therefore this class is only configured
if autoloaded? What if eager loaded? More stuff to explain.
In Rails you typically configure stuff in two ways: config files, or class
level. That is, it is not idiomatic in Rails to split User like
# config/initializers/user_configuration.rb
User.configure do
has_many :posts
end
Rather, you just do it at the class level
class User < ActiveRecord::Base
has_many :posts
end
which happens to play well with autoloading.
Gems do not have to deal with autoloading, they can choose other patterns,
but in Rails we have this constraint, and have to choose idioms that look
good and work well.
--
Sent from Gmail Mobile
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
