Re: Moose and default values

...but the downside is that the default-value is not declared with the attribute but buried in the BUILDer-code and to make this work the attribute has to be "rw".

How about using the initializer option?

use strict;
use warnings;
use 5.012;

package Dog;
use Moose;

has color => (
    is            => "ro", 
    initializer   => sub { my ($self, $attr_val, $setter) = @_; 
                           defined $attr_val or $setter->('black');
                         }
);

my $dog = Dog->new(color => undef);
say $dog->color;

--output:--
black
[download]

I am not so much interested in the feature itself, but it is interesting to see some examples of Moose-metaprogramming at work...

Never mind.

Comment on Re: Moose and default values Download Code

Replies are listed 'Best First'.
Re^2: Moose and default values by tobyink (Canon) on Feb 21, 2013 at 13:17 UTC
Good idea. I don't know why I didn't think of initializers. The Moose cabal aren't especially big fans of initializers, and consider them to be a bit of a misfeature, but this is the kind of niche area they seem to come in handy. Let's take your initializer technique and add some metaprogramming. Read more... (5 kB) For completeness, here's everything in one file. `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply] [d/l] [select]
Re^3: Moose and default values by 7stud (Deacon) on Feb 22, 2013 at 00:06 UTC
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.	[reply]
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]