Re: MooseX obscure error and importance of Unit Testing

The problem is, this is sloppy:

ClassName->new
[download]

It will behave differently depending on whether or not there is a sub called ClassName in the current package. This is a pretty hard to debug error, and is not really Moose's fault. The following snippet illustrates the problem and doesn't use Moose anywhere...

use 5.010;
use strict;
use LWP::UserAgent;

{
  package ClassName;
  sub new { bless [@_], $_[0] }
}
{
  package main;
  sub ClassName () { 'LWP::UserAgent' };
  my $obj = ClassName->new;
  say ref $obj;  # says "LWP::UserAgent"  
}
[download]

The solution is to institute a policy of never using the BareWord->method syntax. Better, and unambiguous ways of writing ClassName->new are:

ClassName::->new
# or...
'ClassName'->new
[download]

Update: aliased is also a rather nice solution.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Comment on Re: MooseX obscure error and importance of Unit Testing Select or Download Code

Replies are listed 'Best First'.
Re^2: MooseX obscure error and importance of Unit Testing by Anonymous Monk on Aug 16, 2012 at 03:23 UTC
The solution is to institute a policy of never using the BareWord->method syntax LOL	[reply]
Re^3: MooseX obscure error and importance of Unit Testing by chromatic (Archbishop) on Aug 16, 2012 at 05:12 UTC
Do you know a more reliable solution, other than constructing optrees by hand?	[reply]
Re^4: MooseX obscure error and importance of Unit Testing (tools) by tye (Sage) on Aug 16, 2012 at 05:22 UTC
I prefer: 1) Don't use tools that make subroutines having the same names as classes. 2) Don't use tools (like old base.pm) that silently ignore failures when you try to require a module. But since I find Moose so strongly pushes toward bad class design (and MooseX::Declare leads to obscure errors and days wasted debugging), not using them is no hardship for me anyway. :) - tye	[reply]
Re^5: MooseX obscure error and importance of Unit Testing (tools) by tobyink (Canon) on Aug 16, 2012 at 07:11 UTC
Re^6: MooseX obscure error and importance of Unit Testing (new tools) by tye (Sage) on Aug 16, 2012 at 07:49 UTC
Re^5: MooseX obscure error and importance of Unit Testing (tools) by stonecolddevin (Parson) on Sep 05, 2012 at 17:48 UTC
Re^6: MooseX obscure error and importance of Unit Testing (tools) by chromatic (Archbishop) on Sep 05, 2012 at 17:59 UTC
Some notes below your chosen depth have not been shown here
Re^6: MooseX obscure error and importance of Unit Testing (tools) by Anonymous Monk on Sep 05, 2012 at 18:48 UTC
Re^4: MooseX obscure error and importance of Unit Testing by Anonymous Monk on Aug 16, 2012 at 07:15 UTC
Do you know a more reliable solution, other than constructing optrees by hand? I don't need one, I manage to avoid writing subroutines that clash with classes, pretty much the same way most of CPAN and everyone else seems to, fairly easily :) Although this might be a candidate :) subs::auto - Read barewords as subroutine names. This pragma lexically enables the parsing of any bareword as a subroutine name, except those which corresponds to an entry in %INC (expected to be class names) or whose symbol table entry has an IO slot (expected to be filehandles).	[reply]