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 -~----------~----~----~----~------~----~------~--~---