I'm sure it's deliberate that after_initialize gets called after an
object is instantiated from the database, but I'm equally sure that
it's a bad idea - if nothing else, initialize doesn't get called
anywhere in the instantiate method chain.
More importantly though, it's a huge performance hit for any
programmer who wants to do something like setting defaults on their
object before it gets written to the database, or even checked for
validity. At present, the only way to get callback behaviour that
triggers only when an object is first made is to do something like:
def after_initialize
if new_record?
do_stuff
end
end
But now she is paying the cost of a method call not only when an
object is initialized (which is fine, because the method actually
_does_) something, but also every time objects of that class are
pulled from the database (an eventuality which is already handled by
the after_find callback.
Being strict and only calling after_initialize from
initialize_with_callbacks and leaving instantiate_with_callbacks only
calling after_find can only make after_initialize more useful. If
someone really does need behaviour common to both points in an
object's lifecycle, it's easy enough to do:
after_find :common_behaviour
after_initialize :common_behaviour
and god is in his heaven and all is right with the world.
If the cost of changing the API in this way is deemed too high, please
at least consider adding some callback that really is only called
after initialization and not after instantiation. It's too useful a
place to ignore.
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
