> 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.
We have before_validation for this case. > 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. Taking the case of 1: @customer = Customer.new(params[:customer]) 2: @customer.do_something 3: @customer.save! What we currently don't have is a hook that will fire before line 2, but not when retrieving from a database. Providing defaults before validation was a common case, and I believe that's where the before_validation hook came from. What other use cases do you have in mind? The name after_initialize is probably a little misleading because it fires even when an object is retrieved from the database. Strictly speaking this is 'initialization', but from a user's perspective it's 'finding' or 'retrieval'. Perhaps at the very least we could give it a less confusing, more hazardous sounding name. -- 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 [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 -~----------~----~----~----~------~----~------~--~---
