Skip Menu |

This queue is for tickets about the Moo CPAN distribution.

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

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

Bug Information
Severity: (no value)
Broken in: 2.002_000
Fixed in: 2.002005



Subject: Moo 2.002_000 breaks colon-in-accessor-names

Prior to 2.002, the following worked:

{
  package Hell;
  use Moo;

  has ':evil_name' => ( is => 'ro', lazy => 1, default => sub { return {} } );
}

After 2.002, the generated accessor tries to generate subs in a package called "Hell:"

and uh.

 

Magic Smoke in Code form leaks out.

 

Eval went very, very wrong:

{
  my $_UNQUOTED = ${$_[1]->{"\$_UNQUOTED"}};
  my $default_for__3aevil_5fname = ${$_[1]->{"\$default_for__3aevil_5fname"}};
  my $_QUOTED = ${$_[1]->{"\$_QUOTED"}};
  package Hell:;
  no warnings 'closure';
  sub evil_name {
  ($_QUOTED,$_UNQUOTED) if 0;
# BEGIN quote_sub PRELUDE
package Method::Generate::Accessor::_Generated;
BEGIN {
  $^H = 1762;
  ${^WARNING_BITS} = "UUUUUUUUUUUUUUUUU\001";
  %^H = (
  );
}
# END quote_sub PRELUDE
    Carp::croak(":evil_name is a read-only accessor") if @_ > 1;
exists $_[0]->{":evil_name"} ? 
$_[0]->{":evil_name"}
:    ($_[0]->{":evil_name"} = $default_for__3aevil_5fname->($_[0]))
  }
  $$_UNQUOTED = \&evil_name;
}
1;


Invalid version format (non-numeric data) at (eval 10) line 5, near ";
  package Hell"
syntax error at (eval 10) line 5, near "package Hell:"
BEGIN not safe after errors--compilation aborted at (eval 10) line 6.
 at /home/kent/perl5/perlbrew/perls/5.25.4-nossp-sdbm-nopmc/lib/site_perl/5.25.4/Method/Generate/Accessor.pm line 135.

 

 

There was a change in how accessors are generated, promoting this to an error at compile time rather than having things explode later. Previously, although a sub with a color (or other invalid identifier) would be generated and installed, if you called there would still be an error. So I think the new behavior is better. The error isn't very friendly though. I've pushed a change so a more reasonable error is shown. RT#116416 was caused by this same change.
Resolved in 2.002005