Skip Menu |

This queue is for tickets about the Moo CPAN distribution.

Report information
The Basics
Id: 81727
Status: resolved
Priority: 0/
Queue: Moo

People
Owner: Nobody in particular
Requestors: djerius [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.000006
Fixed in: (no value)



Subject: Moo::Role->apply_roles_to_object doesn't properly handle consumed attribute defaults
Explicitly applying a role to an object doesn't construct the default value for a consumed attribute.

Here's some code:

----------------------------------------------------
use latest;
use Moo::Role '';

{
  package Role;

  use Moo::Role;

  has a => ( is => 'ro', default => sub { 'default' } );

}

{

  package A;

  use Moo;
  with 'Role';
}

{ package B;

  use Moo;

  has b => ( is => 'ro' );
}

my $a = A->new;

say $a->a;

my $b = B->new;
Moo::Role->apply_roles_to_object( $b, 'Role' );

say $b->a;

----------------------------------------------------

I expected it to output

------------------------
default
default
------------------------

Instead, I got

------------------------
default
Use of uninitialized value in say at test.pl line 35.
------------------------

Am I expecting too much?  I'm expecting 'apply_roles_to_object' to be functionally equivalent to 'with'.

Thanks,

Diab

On Wed Dec 05 15:31:50 2012, DJERIUS wrote: Show quoted text
> Explicitly applying a role to an object doesn't construct the default > value for > a consumed attribute.
You've declared a default that only fires at new() time - it's now long after new() time so it doesn't fire. Show quoted text
> { > package Role; > > use Moo::Role; > > has a => ( is => 'ro', default => sub { 'default' } );
Add lazy => 1 there and things will do what you want.
Subject: Re: [rt.cpan.org #81727] Moo::Role->apply_roles_to_object doesn't properly handle consumed attribute defaults
Date: Sat, 8 Dec 2012 09:18:09 -0800
To: MSTROUT via RT <bug-Moo [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
On Fri, Dec 07, 2012 at 03:01:17PM -0500, MSTROUT via RT wrote: Show quoted text
> You've declared a default that only fires at new() time - it's now long > after new() time so it doesn't fire.
One could possibly argue though that the default doesn't actually fire precisely at new() time, but rather when the attribute springs into existence - so by this reasoning, it would be sensible for the default to fire at the time the attribute appears on the object. I'm saying this without having any idea how complicated it would be to implement, just that having this expectation might not be totally unreasonable.
FYI, Moo seems to differ from Moose here.
I've written a fix for this, which will be included with the next Moo release.
Fixed in 1.003000