On Mon, 25 Oct 2010 15:28:26 -0500, Evan Carroll <[email protected]> wrote: > I'd have assumed that the process went like this: > * BUILDARGS if any
yes > * Moose provided-new which sets the attributes to the values in the hashref > * The default/initializer stage (undefined for the class, defined for > the attribute) * Initialize each attribute in turn, from constructor argument or default/builder Also, I have no idea what your parenthetical means. > * BUILD which gets the complete object yes > However, I'm now seeing this. The non-lazy defaults fire before `foo` > get's set even though foo is explicitly provided. This seems awkward > and counter-intuitive. You can find a test case here > http://gist.github.com/645659 . Could anyone provide commentary on > this behavior? Is this a bug in Moose. I'm on latest stable: 1.17. "Awkward and counter-intuitive" is very subjective and therefore not a compelling reason to change things; for example, people regularly seem to think that it is awkward and counter-intuitive not to override new() when coming from vanilla Perl 5 OO. In this particular case, the way Moose does things means that code related to a given attribute (default, etc.) only sees that particular attribute in a half-built state -- that is, each other attribute is either completely initialized or not at all. This means there's much less opportunity for your object to be exposed in an inconsistent state. hdp.
