moose/MooseX-App-Cmd

Version 0.32 breaks instantiating objects with arguments

Opened this issue · 1 comments

I've managed to come up with a fairly minimal example to demonstrate this problem:

[cibola:~] cat t.pl
use 5.10.1;
use warnings;

use MooseX::App::Cmd;

package Test::App
{   
    use Moose;

    extends 'MooseX::App::Cmd';

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

Test::App->new( foo => 1 );
[cibola:~] cpanm -n MooseX::App::Cmd
--> Working on MooseX::App::Cmd
Fetching http://www.cpan.org/authors/id/E/ET/ETHER/MooseX-App-Cmd-0.32.tar.gz ... OK
Configuring MooseX-App-Cmd-0.32 ... OK
Building MooseX-App-Cmd-0.32 ... OK
Successfully installed MooseX-App-Cmd-0.32 (upgraded from 0.31)
1 distribution installed
[cibola:~] perl t.pl 
Can't use string ("foo") as a HASH ref while "strict refs" in use at /home/buddy/perl5/perlbrew/perls/perl-5.14.4/lib/site_perl/5.14.4/App/Cmd.pm line 285.
[cibola:~] cpanm -n MooseX::App::Cmd@0.31
--> Working on MooseX::App::Cmd
Fetching http://backpan.perl.org/authors/id/E/ET/ETHER/MooseX-App-Cmd-0.31.tar.gz ... OK
Configuring MooseX-App-Cmd-0.31 ... OK
Building MooseX-App-Cmd-0.31 ... OK
Successfully installed MooseX-App-Cmd-0.31 (downgraded from 0.32)
1 distribution installed
[cibola:~] perl t.pl
[cibola:~] 

I'm pretty sure the specific commit is 111df11.

Now, this doesn't come up that often, because most often App::Cmd objects (and their descendants) are instantiated automatically by the larger App::Cmd / MooseX::App::Cmd system, without any arguments whatsoever. However, one good example of when you might want to do this is when writing unit tests for such objects, and you want to short-circuit hard-to-test aspects of the system by providing pre-built attribute values (which is exactly how I stumbled onto this issue).

I would be happy to try to submit a patch, but I'm not entirely sure what problem the original 0.32 change was trying to solve. Obviously any reversion of that change would still have to solve the original problem to be useful. So if anyone could provide any good examples of that issue, I can make sure that any fix I submit addresses that as well.

Were there any thoughts on this? Obviously I can "fix" my problem just by reverting that commit, but I don't want to submit that as a patch, because I feel like there's something else I'm missing. :-)