Bug #88669 for Contextual-Return: redefining blessed breaks Moose

Sat Sep 14 03:57:55 2013 mzrinsky [...] redanvil.net - Ticket created

Subject:

redefining blessed breaks Moose

Moose and Moose::Role make blessed available to modules that use Moose; or use Moose::Role; Using Contextual::Return anywhere in any module clobbers that. In my case I was using IO::Prompter, which makes use of Contextual::Return and that caused modules looking for blessed to fail to find it with a undefined subroutine the::module::blessed error. Version 0.004003 and before do not have this error (as blessed was not overridden then). I'm not sure what the real problem is between the 2 modules, as I only use Contextual::Return indirectly through the IO::Prompter module as mentioned.

Wed Sep 25 02:39:49 2013 damian [...] conway.org - Correspondence added

Subject:	Re: [rt.cpan.org #88669] redefining blessed breaks Moose
Date:	Wed, 25 Sep 2013 16:38:56 +1000
To:	bug-Contextual-Return [...] rt.cpan.org
From:	Damian Conway <damian [...] conway.org>

Show quoted text

> Moose and Moose::Role make blessed available to modules that use Moose; or use Moose::Role; > Using Contextual::Return anywhere in any module clobbers that.

Thanks for the report. I am surprised by this, but have been unable to reproduce the problem. Could you possibly send me a (short!) code example than demonstrates the problem? Thanks, Damian

Wed Sep 25 02:39:50 2013 The RT System itself - Status changed from 'new' to 'open'

Thu May 29 06:42:19 2014 BRAD [...] cpan.org - Correspondence added

RT-Send-CC:

damian [...] conway.org, damian [...] conway.org

Hi Damian, I'm getting the same, adding IO::Prompter to an existing Moose project. I'm attaching a snippet of code that produces the attached error without needing any objects defined - swapping the order of use for TryCatch and IO::Prompter solves the issue. Cheers Brad

Subject:

IO__Prompter-error-message.txt

[5s] ./test.pl --arg Can't locate object method "blessed" via package "MooseX::Types::EXPORTED_TYPE_CONSTRAINT" at /home/brad/perl5/lib/perl5/MooseX/Types.pm line 385. BEGIN failed--compilation aborted at /home/brad/perl5/lib/perl5/Parse/Method/Signatures/Types.pm line 18. Compilation failed in require at /home/brad/perl5/lib/perl5/Parse/Method/Signatures/ParamCollection.pm line 5. BEGIN failed--compilation aborted at /home/brad/perl5/lib/perl5/Parse/Method/Signatures/ParamCollection.pm line 5. Compilation failed in require at /home/brad/perl5/lib/perl5/Parse/Method/Signatures.pm line 11. BEGIN failed--compilation aborted at /home/brad/perl5/lib/perl5/Parse/Method/Signatures.pm line 11. Compilation failed in require at /home/brad/perl5/lib/perl5/x86_64-linux-thread-multi/TryCatch.pm line 11. BEGIN failed--compilation aborted at /home/brad/perl5/lib/perl5/x86_64-linux-thread-multi/TryCatch.pm line 11. Compilation failed in require at ./test.pl line 16. BEGIN failed--compilation aborted at ./test.pl line 16.

Subject:

IO__Prompter-error.pl

#!/usr/bin/env perl BEGIN { use version; our $VERSION = qv('1.0.0') } use strict; use warnings; use utf8; use English; use open IO => ':utf8'; #use Getopt::Euclid; #use Params::Validate qw(:all); #use Smart::Comments -ENV; use IO::Prompter; use TryCatch; 1;

Thu May 29 16:41:50 2014 damian [...] conway.org - Correspondence added

Subject:	Re: [rt.cpan.org #88669] redefining blessed breaks Moose
Date:	Fri, 30 May 2014 06:41:01 +1000
To:	bug-Contextual-Return [...] rt.cpan.org
From:	Damian Conway <damian [...] conway.org>

Hi Brad, Show quoted text

> I'm getting the same, adding IO::Prompter to an existing Moose > project. I'm attaching a snippet of code that produces the attached > error without needing any objects defined - swapping the order of use > for TryCatch and IO::Prompter solves the issue.

Thanks for the minimalist example. Tracking through the problem, this seems to be a bad interaction between Scalar::Util, Moose::Exporter, and Contextual::Return under 5.18 and later. Unfortunately, it doesn't seem to be an interaction that I can fix via Contextual::Return (which is the only one of those three modules I control). There's a simple fix via MooseX::Types, which is to change the line: use Scalar::Util 'reftype'; to: use Scalar::Util 'reftype', 'blessed'; The only other alternative, as you have already discerned, is to ensure that IO::Prompter loads after Moose. Even just putting: use Moose (); at the start of the main program solves the problem. Sorry not to be of more help, Damian

Mon Jun 02 03:49:48 2014 mzrinsky [...] redanvil.net - Correspondence added

From:

mzrinsky [...] redanvil.net

I don't know why, but I never thought to swap the order of the modules. Moving IO::Prompter to be the last module loaded worked. Just for the heck of it here is an additional test case that shows the issue. Either way, it is resolved for me now anyway by just making sure IO::Prompter is the last module loaded. Thanks!

Subject:

blessed_bug.pl

use strict; use warnings; use lib qw'.\/'; use IO::Prompter; use TestClass; my $t = TestClass->new(); $t->test();

Subject:

TestClass.pm

package TestClass; use Moose; sub test { my $self = shift; my $t = bless({}, 'base_test_1'); return blessed($t); } 1;

Fri Oct 24 13:27:02 2014 ether [...] cpan.org - Correspondence added

RT-Send-CC:

damian [...] conway.org

On 2014-05-29 13:41:50, damian@conway.org wrote: Show quoted text

> Hi Brad, >

> > I'm getting the same, adding IO::Prompter to an existing Moose > > project. I'm attaching a snippet of code that produces the attached > > error without needing any objects defined - swapping the order of use > > for TryCatch and IO::Prompter solves the issue.

> > Thanks for the minimalist example. > > Tracking through the problem, this seems to be a bad interaction between > Scalar::Util, Moose::Exporter, and Contextual::Return under 5.18 and later. > > Unfortunately, it doesn't seem to be an interaction that I can fix via > Contextual::Return (which is the only one of those three modules I control). > > There's a simple fix via MooseX::Types, which is to change the line:

Now that I am aware of this issue, I am making this patch, and similar patches in other code (a core Moose module is similarly affected). PLEASE IN FUTURE raise tickets on the other affected modules!!!!!

Fri Oct 24 13:31:04 2014 ether [...] cpan.org - Correspondence added

On 2014-05-29 13:41:50, damian@conway.org wrote: Show quoted text

> Tracking through the problem, this seems to be a bad interaction between > Scalar::Util, Moose::Exporter, and Contextual::Return under 5.18 and later. > > Unfortunately, it doesn't seem to be an interaction that I can fix via > Contextual::Return (which is the only one of those three modules I control).

This *is* fixable in Contextual-Return, by the way -- the problem is that the patched version of the function is not being named. All you need to do is wrap it in a call to Sub::Name::subname (or Sub::Util::set_subname, a modern clone of this implementation).

Fri Oct 24 13:31:27 2014 ether [...] cpan.org - Cc ETHER added

Fri Oct 24 13:50:58 2014 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Fri Oct 24 13:31:04 2014, ETHER wrote: Show quoted text

> On 2014-05-29 13:41:50, damian@conway.org wrote: >

> > Tracking through the problem, this seems to be a bad interaction > > between > > Scalar::Util, Moose::Exporter, and Contextual::Return under 5.18 and > > later. > > > > Unfortunately, it doesn't seem to be an interaction that I can fix > > via > > Contextual::Return (which is the only one of those three modules I > > control).

> > This *is* fixable in Contextual-Return, by the way -- the problem is > that the patched version of the function is not being named. All you > need to do is wrap it in a call to Sub::Name::subname (or > Sub::Util::set_subname, a modern clone of this implementation).

If you don’t want Contextual::Return to depend on more modules, you could also eval 'sub Scalar::Util::blessed {...}' to accomplish the same thing, instead of *Scalar::Util::blessed=sub{...}.