On Mon, 25 Oct 2010 16:23:45 -0500, Evan Carroll <m...@evancarroll.com> wrote: > I'll go ahead and > show you what I wanted to do with this. I have a Class, it should > accept either a "company_id", or a hash of "attributes" if you provide > a company_id the attribute hash is lazy when it is needed. If you > provide a hash of company attributes, then the value is immediately > entered into the DB, and the company_id gets set appropriately:
Using new() for this seems wrong to me. Your object constructor should construct objects, not construct objects and sometimes insert data but other times retrieve it. For example, in DBIC this is find_or_create, which is itself built on top of other predicates that are built on top of object construction; it's a complex operation, and trying to make it all an inextricable part of calling new is a code smell. If you insist on doing it anyway, I don't think you'll find any support for the approach you've chosen, because we've repeatedly said that using 'lazy' on everything is the right way to deal with this kind of attribute interdependency. Using lazy already gives you the initialization order that you want. In this particular case, you could mark everything as lazy and resolve it in BUILD. If you find that unappealing, this would also be a good use of the hypothetical "lazy default/builder, but call it automatically after initialization" attribute trait/option that's come up with some frequency in the past, if you felt like writing that. hdp.
