Skip Menu |

This queue is for tickets about the MooseX-MungeHas CPAN distribution.

Report information
The Basics
Id: 92557
Status: resolved
Priority: 0/
Queue: MooseX-MungeHas

People
Owner: perl [...] toby.ink
Requestors: mascip [...] gmail.com
Cc:
AdminCc:

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



Subject: problem caused by the call to Moose::Util::TypeConstraint ::find_or_parse_type_constraints($_{isa})
Date: Wed, 29 Jan 2014 12:26:09 +0000
To: bug-MooseX-MungeHas [...] rt.cpan.org
From: mascip <mascip [...] gmail.com>
Hi Toby, line number 67, in compile_munger_code(), causes me a problem (bug?). It's this line: push @code, ' $_{isa} = '._detect_oo($caller).'::Util::TypeConstraints::find_or_parse_type_constraint($_{isa});'; Here is enough code to provoke the bug: package Bfp::API; use OX; # use Moose; here leads to the exact same bug use MooseX::MungeHas 'is_ro'; has view => ( isa => 'OX::View::TT' ); I've added some print statements in MooseX::MungeHas, and found that before line 67, $_{isa} is equal to 'OX::View::TT' but after that line it is undef, because Moose::Util::TypeConstraints::find_or_parse_type_constraint($_{isa}) doesn't "find" nor "detects" the 'OX::View::TT' type. I'm not sure whether it's a bug in Moose::Util::TypeConstraints (I'm not sure how its $REGISTER and find_or_parse_type_constraint() are supposed to behave exactly), or whether MooseX::MungeHas should not be using this function - or use something else instead. But I have tried to simply comment line 67 in MooseX::MungeHas, and there is no more bug: everything seems to work seamlessly. What is the purpose for calling this function here? Do we really need it sometimes? I have made one additional experiment which might give some insight. By adding one line in the code: use OX::View::TT; the type is found and everything works well. But that's annoying: without MooseX::MungeHas I didn't need to add this line. Why would I now have to? That's especially annoying if I've got a few classes with a few attributes each: for each attribute, I'm going to have to add the right "use" line if I want to use MooseX::MungeHas. There's no rush in fixing this problem for me: right now I'm using your code with line 67 commented and it works. But that feels potentially dangerous. PS: Ah! I forgot to write the minimal extra amount of code that i use to run this code: package Bfp; use OX; use Bfp::API; router as { mount '/api' => 'Bfp::API', ( view_index => 'view', ); }; which I run with plackup -Ilib bin/app.psgi
I know that Moose does occasionally have trouble if you use a class name or role name as a type constraint without first loading that package. For example, try this: BEGIN { package Bar; use Moose; }; BEGIN { package Foo; use Moose; has bar => (is => 'ro', isa => 'Undef|Bar'); }; my $x = Foo->new( bar => Bar->new ); print $x->dump; Now try reversing the order of the two BEGIN blocks. I imagine that the problem is this kind of thing. It's probably resolvable somehow though.
Subject: Re: problem caused by the call to Moose::Util::TypeConstraint ::find_or_parse_type_constraints($_{isa})
Date: Wed, 12 Feb 2014 11:34:54 +0000
To: bug-MooseX-MungeHas [...] rt.cpan.org
From: mascip <mascip [...] gmail.com>
I think that might be it. But then why do I not get the bug when I don't use MooseX::MungeHas, but get it when I use this module?​ Is it because MooseX::MungeHas executes Moose::Util: :TypeConstraints::find_or_parse_type_constraint() earlier than Moose would? It's just a naive thought, but I feel like MooseX::MungeHas might be re-coding part of Moose's job. What is the reason for that? I've just realized that the code for MooseX::AttributeDefaults is only 10 lines long... but I'm guessing that it is only Moose-compatible. Is that why MooseX::MungeHas has to re-do a lot of the work? For Mo(o|ose|use)? cross-compatibility?
On 2014-01-29 04:27:00, mascip wrote: Show quoted text
> Hi Toby, > > line number 67, in compile_munger_code(), causes me a problem (bug?). > It's > this line: > push @code, ' $_{isa} = > '._detect_oo($caller).'::Util::TypeConstraints::find_or_parse_type_constraint($_{isa});';
Why parse the type constraint line at all? just pass it upwards to Moose::Meta::Attributes::_process_options. PS. you created a new ticket with your reply - those tickets should be merged together. Keep the ticket it in the subject and the response will be added to the right ticket.
On 2014-02-12T16:42:09Z, ETHER wrote: Show quoted text
> Why parse the type constraint line at all? just pass it upwards to > Moose::Meta::Attributes::_process_options.
The type constraint is parsed because MooseX::MungeHas has a few optional features that need the parsed constraint. For example it has an "always_coerce" option which automatically switches on coercions for type constraints which have coercions. So it needs the type constraint object rather than a string. I think what MooseX::MungeHas needs to do is use find_or_create_isa_type_constraint instead of find_or_parse_type_constraint. (This is what Moose::Meta::Attribute does!)
Show quoted text
> I think what MooseX::MungeHas needs to do is use > find_or_create_isa_type_constraint instead of > find_or_parse_type_constraint. (This is what Moose::Meta::Attribute > does!)
Pierre, could you please try this change on your local copy of MooseX::MungeHas and see if it fixes the issue?
Subject: Re: [rt.cpan.org #92557] problem caused by the call to Moose::Util::TypeConstraint ::find_or_parse_type_constraints($_{isa})
Date: Thu, 13 Feb 2014 17:13:07 +0100
To: bug-MooseX-MungeHas [...] rt.cpan.org
From: mascip <mascip [...] gmail.com>
It does, thank a lot to you two!
On 2014-02-13T16:13:55Z, mascip wrote: Show quoted text
> It does, thank a lot to you two!
Excellent. I'll try to get a release out tomorrow with this change.
Fixed in 0.005.