Re^3: Moose and default values

The Moose cabal aren't especially big fans of initializers, and consider them to be a bit of a misfeature,

Why is that? The only thing I can find is the following from Moose::Manual:BestPractices:

Don't use the initializer feature

Don't know what we're talking about? That's fine.

Uh, okay, but I do know what you are talking about. The manual's reasoning for that best practice doesn't quite rise to the level of a Damian Conway best practice.

Comment on Re^3: Moose and default values

Replies are listed 'Best First'.
Re^4: Moose and default values by tobyink (Canon) on Feb 22, 2013 at 11:41 UTC
"Why is that?" Good question. I wasn't sure myself. I seem to recall RJBS saying that initializers were his first ever contribution to Moose, but that he regretted ever adding them. The best reasons I could come up with were: It leads to inconsistent behaviour when an attribute value is set via the constructor versus a writer method. (Of course, this isn't an issue for read-only attributes.) Initializers can't be inlined whereas type coercions can be partly compiled into a more efficient form, and have potential for improvement. Having asked in #moose, I've had the following additional suggestions: The initializer isn't called until after type constraints have been checked, so initializers don't work for one of the main use cases you'd expect them to be useful for: to munge values to conform to their type constraints. (I'll add to this list when I receive more responses from IRC.) `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply]

Replies are listed 'Best First'.

Re^4: Moose and default values
by tobyink (Canon) on Feb 22, 2013 at 11:41 UTC

"Why is that?"

Good question. I wasn't sure myself. I seem to recall RJBS saying that initializers were his first ever contribution to Moose, but that he regretted ever adding them.

The best reasons I could come up with were:

It leads to inconsistent behaviour when an attribute value is set via the constructor versus a writer method. (Of course, this isn't an issue for read-only attributes.)
Initializers can't be inlined whereas type coercions can be partly compiled into a more efficient form, and have potential for improvement.

Having asked in #moose, I've had the following additional suggestions:

The initializer isn't called until after type constraints have been checked, so initializers don't work for one of the main use cases you'd expect them to be useful for: to munge values to conform to their type constraints.
(I'll add to this list when I receive more responses from IRC.)

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

[reply]