Rails core - Mar 2008 - after_inialize and after_find class methods are broken?

The after_find and after_initialize callbacks work fine when defined as
instance methods like so:

class User < ActiveRecord::Base
  def after_initialize
    self.name = ''Mc Gumbo''
  end
end
User.new.name # => ''Mc Gumbo''

But the alternative version doesn''t get fired:

class User < ActiveRecord::Base
  after_initialize :name_mc_gumbo

  def name_mc_gumbo
    self.name = ''Mc Gumbo''
  end
end
User.new.name # => nil

The funny thing is that the second form raises no errors, properly defines
the callback, and is just waiting for the callback to be triggered.  All it
would take (I think) to make it work and not decrease performance changing
the ActiveRecord::Base.instantiate from this:
if object.respond_to_without_attributes?(:after_initialize)
  object.send(:callback, :after_initialize)
end

to this:

if object.respond_to_without_attributes?(:after_initialize) ||
object.class.instance_variable_get("@after_initialize_callbacks")
  object.send(:callback, :after_initialize)
end

Is this worth a ticket or am I missing something?

::Jack Danger

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

> Is this worth a ticket or am I missing something?
It''s mentioned in the documentation:

"Because after_find and after_initialize are called for each object
found and instantiated by a finder, such as Base.find(:all), 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 (def after_find). In that case, all of the callback types will
be called."

-- 
Cheers

Koz

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

On Tue, Mar 25, 2008 at 2:47 PM, Michael Koziarski <michael@koziarski.com>
wrote:
>
> > Is this worth a ticket or am I missing something?
>
> It''s mentioned in the documentation:
>
Thanks for pointing that out Koz.  I think I didn''t understand from the
documentation that defining the explicit method was the way to trigger all
the shorthand callbacks.  I might patch up the documentation to help
cleverness-impaired folks like me.

::Jack Danger

>
> "Because after_find and after_initialize are called for each object
> found and instantiated by a finder, such as Base.find(:all), 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 (def after_find). In that case, all of the callback types will
> be called."
>
> --
> Cheers
>
> Koz
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---