A recent post on the StackOverflow beta (http://beta.stackoverflow.com/
questions/10808/ruby-mixins-and-calling-super-methods#11866 for those
who are on it) discusses a problem with chaining after_initialize
definitions from multiple mixin modules. The problem is that each
module must use alias_method_chain (or call super) to make sure the
other after_initialize calls are executed, but models don''t define
after_initialize by default. The first module included can''t chain to
the non-existent definition.
The proof:
class Foo < ActiveRecord::Base
end
Foo.method_defined? :after_initialize
=> false
The solution is
ActiveRecord::Base
def after_initialize
#nothing
end
end
I can see a counter-argument to putting this in core: if you''re going
to include the mixin, you should be defining it yourself. But I''m not
convinced. I don''t see any reason why there aren''t default
(empty)
implementations of every callback method. Doing so would obviate the
check during object creation, which can only be a good thing.
--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
> I can see a counter-argument to putting this in core: if you''re going > to include the mixin, you should be defining it yourself. But I''m not > convinced. I don''t see any reason why there aren''t default (empty) > implementations of every callback method. Doing so would obviate the > check during object creation, which can only be a good thing.See this reasoning as listed in the rdoc: # == The +after_find+ and +after_initialize+ exceptions # # Because +after_find+ and +after_initialize+ are called for each object found and instantiated by a finder, such as <tt>Base.find(:all)</tt>, we''ve had # to implement a simple performance constraint (50% more speed on a simple test case). Unlike all the other callbacks, +after_find+ and # +after_initialize+ will only be run if an explicit implementation is defined (<tt>def after_find</tt>). In that case, all of the # callback types will be called. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---