Received: by 10.35.130.15 with SMTP id h15mr3729995pyn.1185297637901;
        Tue, 24 Jul 2007 10:20:37 -0700 (PDT)
Return-Path: <ara.t.how...@gmail.com>
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239])
        by mx.google.com with ESMTP id a28si1736349pye.2007.07.24.10.20.36;
        Tue, 24 Jul 2007 10:20:37 -0700 (PDT)
Received-SPF: pass (google.com: domain of ara.t.how...@gmail.com designates 64.233.162.239 as permitted sender)
DomainKey-Status: good (test mode)
Received: by nz-out-0506.google.com with SMTP id o1so1338009nzf
        for <rubyonrails-core@googlegroups.com>; Tue, 24 Jul 2007 10:20:36 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=eNuhlw2BTOag5bSNnVOCsYrYlq0TWhwKpblUgx8xavvsbotLk4N3aTJB5WfH758u5tVDnuUii5dSPd4pJANZzK/0cllFS0krhP8pm6JQFXx4eQxOJ6tgv7S9AunXcvqnsINWd3zDxQTzWREJpfjQRORPKZQBDYqgUQ6EE11I1ZQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=eiNccocVlfFavJGIXdSVkMCqPfua9FeCRQcCdSDjm40OPwOtcABrQeH+GIBE2F2FPv/SFBxuMObSoBGifq9z6Fdf5zULU/+kwxwQVVp8NrcX6x+6uXD7UVKyNRoJUeKsqnSa3dhJWR8gEIoZ6zLGaJvibk92lrzZODavfwRWZbw=
Received: by 10.114.94.1 with SMTP id r1mr4272919wab.1185297636411;
        Tue, 24 Jul 2007 10:20:36 -0700 (PDT)
Return-Path: <ara.t.how...@gmail.com>
Received: from ?140.172.8.159? ( [140.172.8.159])
        by mx.google.com with ESMTPS id v39sm7596276wah.2007.07.24.10.20.36
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 24 Jul 2007 10:20:36 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <ef46c93e0707221539m78994c1em9ec31bb5d8cee9e1@mail.gmail.com>
References: <897e96cc0707220254l750943a2naeab8aaf0249917a@mail.gmail.com> <ef46c93e0707221102q4d34cab8hf0e825aa0a651cb4@mail.gmail.com> <897e96cc0707221150k776ae7fbgdc6997670c04b...@mail.gmail.com> <ef46c93e0707221425r5c94a631t4d108d6cc68f...@mail.gmail.com> <897e96cc0707221453t31d07295y7f6d39cf421f6...@mail.gmail.com> <ef46c93e0707221539m78994c1em9ec31bb5d8cee...@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5729E142-D7DD-4570-B0B8-C6A98AA85...@gmail.com>
Content-Transfer-Encoding: 7bit
From: "ara.t.howard" <ara.t.how...@gmail.com>
Subject: Re: [Rails-core] Re: after_initialize/after_find misfeature
Date: Tue, 24 Jul 2007 11:21:11 -0600
To: rubyonrails-core@googlegroups.com
X-Mailer: Apple Mail (2.752.3)


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