On Jul 22, 2007, at 4:39 PM, Michael Koziarski wrote:
>
> I can buy your argument, but if I do so, there doesn't seem to be a
> need for after_initialize:
>
> def initialize(attrs)
> do_stuff
> super
> end
>
> All we'd be doing is reinventing an initialize method which hid the
> arguments. Doesn't seem particularly necessary, especially at the
> cost of backwards compatibility for the people who use
> after_initialize at present.
>
the trick, of course, is that attrs are sometimes nil - also we
(client code) don't know what/if any block might be, or not be,
for... i just had this issue last week and here is how i solved it
class Agent < ActiveRecord::Base
def initialize options, &block
super((options || {}).reverse_merge!(defaults), &block)
end
def defaults
Hash.new
end
end
this is used in an STI situation so i also have code like this
class Group < Agent
def defaults
{
'allow_login' => false,
}
end
end
class User < Agent
def defaults
{
'allow_login' => true,
}
end
end
and this seems to be working well. so my own suggestion wouldn't be
so much for another callback but a way to simply set the defaults for
a record, perfering a method over a hash so that current object state
and arbitrary logic might affect the result, Time.now, for instance.
also, i strongly agree that this is a giant hole in the ar lifecycle.
kind regards.
a @ http://drawohara.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
