On Mon, Oct 25, 2010 at 03:28:26PM -0500, Evan Carroll wrote:
> I've recently discovered that rather against my own intuition Moose
> does not set constructor provided arguments first. I've always thought
> that Moose did the logical thing here.. If I was to read the code
> here:
>
> Class->new({ foo => bar })->baz;
>
> I'd have assumed that the process went like this:
> * BUILDARGS if any
> * 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)
> * BUILD which gets the complete object
>
> 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.
This is not a bug. Attribute initialization order is explicitly
undefined (the documentation mentions this in several places). If you
need a defined initialization order, you should make the appropriate
attributes lazy.
-doy
