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({
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.
That's not how I read that statement. When you say attribute
On Mon, 25 Oct 2010 15:28:26 -0500, Evan Carroll m...@evancarroll.com 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
Also, I have no idea what your parenthetical means.
Parenthetical indicate that I know default fires before the
initializer for the attribute, but that not all defaults for all
attributes will fire before any of the initializers. Currently, an
Attribute process not a class process.
Awkward and
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
