Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Mouse CPAN distribution.

Report information
The Basics
Id: 61076
Status: open
Priority: 0/
Queue: Mouse

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

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



Subject: Mouse creates an implied type
Download (untitled) / with headers
text/plain 965b
If you use an undeclared type and then try to create a subtype with the same name, Mouse squeaks that the type already exists. { package Foo; use Mouse; has bar => is => 'rw', isa => 'Positive_Int' ; } { package My::Types; use Mouse::Util::TypeConstraints; subtype 'Positive_Int' => ( as 'Int', where { $_ >= 0 }, ); } __END__ The type constraint 'Positive_Int' has already been created in Mouse::Util::TypeConstraints and cannot be created again in My::Types at /Users/schwern/tmp/test.plx line 25 Moose does not have a problem with this. I discovered this when I accidentally used a subtype before loading my custom Types module. The load order was subtle, so it wasn't immediately obvious what was happening. The error message saying that the constraint had been created inside TypeConstraints was very puzzling leading me to believe I'd somehow recreated an undocumented internal Mouse type.
Download (untitled) / with headers
text/plain 617b
Hi, Michael. I know that that behavior you reported is different from Moose's. I believe that the behavior itself (i.e. throwing the error) is correct, but I admit that the message is confusing. So I have improved the error message: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/Mouse.git;a=blobdiff;f=lib/Mouse/Util/TypeConstraints.pm;h=97de7179c47b175e8785de5ebd7c0381e82309b9;hp=f786e09fe49431785904806d776cde3b9887d068;hb=b6f6f7b2fcaeacaecaf85662e7a1ff2c87b087e2;hpb=5ab8f626029ab9c2e9ec7988d9dd519e2efa223a What do you think of it? Is it a good solution? Regards, -- Goro Fuji (gfx) GFUJI at CPAN.org
Subject: Re: [rt.cpan.org #61076] Mouse creates an implied type
Date: Sun, 05 Sep 2010 22:44:39 -0700
To: bug-Mouse [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Download (untitled) / with headers
text/plain 1.5k
On 2010.9.5 9:23 PM, Goro Fuji via RT wrote: Show quoted text
> I know that that behavior you reported is different from Moose's. > I believe that the behavior itself (i.e. throwing the error) is correct, > but I admit that the message is confusing. > > So I have improved the error message: > http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/Mouse.git;a=blobdiff;f=lib/Mouse/Util/TypeConstraints.pm;h=97de7179c47b175e8785de5ebd7c0381e82309b9;hp=f786e09fe49431785904806d776cde3b9887d068;hb=b6f6f7b2fcaeacaecaf85662e7a1ff2c87b087e2;hpb=5ab8f626029ab9c2e9ec7988d9dd519e2efa223a > > What do you think of it? Is it a good solution?
I can't say if its a solution, but it sure helps to make the situation less mysterious. Thank you. :) Would it be possible for it to point the reader where the type was implicitly created? That's likely where the typo or missing use of a custom type module would be. My thoughts on the overall behavior... a declared subtype() probably shouldn't *silently* plow over an implied class type like Moose does (I haven't checked to see what Moose is really doing, if the subtype or class type wins, just that it has no error). It does run the risk of a type clashing with a class name... but I guess that's a problem inherent in the system and with using string type names instead of symbolic ones like I should be. If you pushed me to decide, I'd decide on it being an error. But I'd also decide on making Moose and Mouse do the same thing, thus pushing it upstream to Moose. -- Stabbing you in the face so you don't have to.
Download (untitled) / with headers
text/plain 1.3k
On Mon Sep 06 01:44:54 2010, schwern@pobox.com wrote: Show quoted text
> I can't say if its a solution, but it sure helps to make the situation > less > mysterious. Thank you. :) Would it be possible for it to point the > reader > where the type was implicitly created? That's likely where the typo > or > missing use of a custom type module would be.
It will be better that we know where a type constraint was created. I'll try it. Show quoted text
> My thoughts on the overall behavior... a declared subtype() probably > shouldn't > *silently* plow over an implied class type like Moose does (I haven't > checked > to see what Moose is really doing, if the subtype or class type wins, > just > that it has no error). It does run the risk of a type clashing with a > class > name... but I guess that's a problem inherent in the system and with > using > string type names instead of symbolic ones like I should be. > > If you pushed me to decide, I'd decide on it being an error. But I'd > also > decide on making Moose and Mouse do the same thing, thus pushing it > upstream > to Moose. > >
The current behaviour of Moose in the script you reported is that Moose deals with the first 'Positive_Int' as a class type, and deals with the second 'Positive_Int' as a custom subtype. This behaviour seems confusing, so I'll report it to Moose team. Thanks, -- Goro Fuji (gfx) GFUJI at CPAN.org


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.