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](http://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](http://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

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."

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