Evan,
I want to take these problems seriously, since it's clear to me that some of these changes break things that should work. However, some thing that passed (but silently failed to do anything useful) are now breaking loudly. So we need to detangle all this and build up some test cases we can crank against. Specific comments follow:
--- On Fri, 6/12/09, Evan Carroll via RT <bug-MooseX-Types@rt.cpan.org> wrote:
Show quoted text> From: Evan Carroll via RT <bug-MooseX-Types@rt.cpan.org>
> Subject: [rt.cpan.org #46891] Drawbacks of .11
> To:
> Date: Friday, June 12, 2009, 2:20 PM
>
> Queue: MooseX-Types
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=46891 >
>
> Ok, first I wanted to confirm this stuff. CPANPLUS was
> being mega
> shitass, and I just filed a bug on it too for failing to
> downgrade by url.
>
> So the deal is, in .10, the following code works:
> package Foo;
> use MooseX::Types;
> subtype "foo" => as "Int";
> subtype "bar" => as "foo";
Yes, now when you load MooseX::Types the subtype method is getting intercepted so declaring global string based stuff is not working anymore. This is a side effect of trying to solve the problem of people incorrectly stringifying the subtype name by using => over ,. Unfortunately this error is one of the more common ones with MX::Types and it too often is silently failing. A core assumption here is that if you are using MX:Types you intend to use it and not mix and match global string types. We can make that a point of discussion.
Show quoted text>
> However, in .11 you can't write it the same way, that same
> code gives
> you this.
> WARNING: String found where Type expected (did you use a
> => instead of a
> , ?) at -e line 1
> WARNING: String found where Type expected (did you use a
> => instead of a
> , ?) at -e line 1
> WARNING: String found where Type expected (did you use a
> => instead of a
> , ?) at -e line 1
> WARNING: String found where Type expected (did you use a
> => instead of a
> , ?) at -e line 1
>
> Logically, you've made the types consistent on Barewords (I
> strongly
> would have preferred a string solution for consistency, but
> whatever).
> So I try to remove the strings, and the fat commas.
> package Foo;
> use MooseX::Types;
> subtype foo , as Int;
> subtype bar , as foo;
>
> But nothing is in your package, so you have
> MooseX::Types::Moose pollute
> you with the Int, and now, new to .10 you have to declare
> things even if
> they aren't exported (as in internal base types).. so you
> try
> package Foo;
> use MooseX::Types::Moose qw(Int);
> use MooseX::Types -declare qw(foo bar);
> subtype foo , as Int;
> subtype bar , as foo;
Yes, I think you should be able to use the old string stuff in the 'as' clause. However, this was probably silently failing on you, since the "as 'Int'" would be meaningly without 'use Moose'. So my guess in that case you'd not get a failure but the type constraint library was failing to do anything useful.
Show quoted text>
> Finally, you have joy -- kinda, this begs the question on
> how you
> declare an unexported base type. You think you've got it,
> but still no
> joy. Now with .11 Roles that where composed into classes
> that used the
> MX::Types library have to also use the MX::Types library --
> this might
> be a good thing, but it certainly isn't backwards compat.
> So you go back
> and look at your code add the missing includes for the
> Types and save
> and try again. Does it work yet? Nope, because now that
> you're using
> Barewords you have to use Explicitly code all of the
> variables into
> Sub::Exporter, whereas in .10 you you could use strings,
> and thus only
> had to put the subs you wanted exported too in
> Sub::Exporter...
>
More test cases with roles are called for. However I would imagine my previous comment about "it used to work" stands. It probably failed to warn or throw an error before, but it probably wasn't constraining anything.
Show quoted text> So finally, after you've got rid off all of the
> stringifications with
> quotes and fat commas, and you've replaced all base types
> with
> MooseX::Types::Moose barewords, and you updated
> Sub::Exporter to export
> all of those barewords now... You ask the question, do I
> have joy yet?
> Nope. And, why is that you ask..
>
> Could not load class (DM::IO::Input::File) because : Could
> not load
> class (DM::IO::Input::Base::Index) because : Could not
> locate type
> constraint (Money) for the union at
> /usr/local/share/perl/5.10.0/Moose/Util/TypeConstraints.pm
> line 87
>
> Fuck! A 2 month old critical bug on rt was less important
> than this?
> Jesus. Christ. So now I can't use a type-union with
> MooseX::Types and Undef.
>
> package Foo;
> use MooseX::Types::Moose qw(Int);
> use MooseX::Types -declare => [qw(foo bar)];
> subtype foo , as Int;
> subtype bar , as foo;
>
> package WTF;
> use Moose;
> Foo->import( 'foo', 'bar' );
>
> ## No workie
> has 'mutatedtype' => ( isa => 'foo | Undef', is =>
> 'rw' );
> ## workie
> has 'mutatedtype' => ( isa => 'foo', is => 'rw'
> );
>
>
> This used to work before, not being able to do this is
> going to prevent
> successful migration to .11.
Well, again, the above would have not constrained anything. in this case 'foo' is nothing.
You could do
isa=> Foo|Undef
isa=> Maybe[Foo]
Undef and Maybe you can import from MooseX::Types::Moose qw(Undef Maybe)
Show quoted text> At least before I could use
> the
> global-string-types version and get this working.
>
> As as a side note the docs for migration are really needed
> here, I
> really had to like 4 steps to get this to even `perl -c`
> with .11.
>
Docs would probably be usefull.
The core issue here is that people were improperly using this stuff and getting silent fails. Now they are getting loud fails. Also, some stuff is failing that probably should work. We need to detangle it all.
Thanks for the thoughts and the detailed report.
RT for rt.cpan.org