This queue is for tickets about the Method-Signatures CPAN distribution.

Report information
The Basics
Id:
88716
Status:
open
Priority:
Low/Low

People
Owner:
BAREFOOT [...] cpan.org
Requestors:
mst [...] shadowcat.co.uk
Cc:
ether [...] cpan.org
AdminCc:

BugTracker
Severity:
Important
Broken in:
(no value)
Fixed in:
(no value)



Subject: Use of deprecated Any::Moose
Date: Mon, 16 Sep 2013 23:51:40 +0000
To: bugs-Method-Signatures@rt.cpan.org
From: Matt S Trout <mst@shadowcat.co.uk>
As documented, this is now deprecated in favour of Moo - see http://shadow.cat/blog/matt-s-trout/moo-versus-any-moose/ for an explanation of why Any::Moose is broken by design. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.
Show quoted text
> As documented, this is now deprecated in favour of Moo ...
Trust me, if it were just a matter of replacing `Any::Moose` with `Moo`, it would be done by now. But the only thing we use Mouse/Moose for is the types, and Moo doesn't really have types. (There's MooX::Types::MooseLike, but it's not really a drop-in replacement.) So we were stuck on how to approach it for a while there. The current thinking, though, is to drop Moose/Mouse altogether and go with Type::Tiny / Types::Standard (see [GitHub #81](https://github.com/schwern/method-signatures/issues/81)). So hopefully I can find the tuits to tackle that very soon.
CC: ether@cpan.org
Subject: Re: [rt.cpan.org #88716] Use of deprecated Any::Moose
Date: Thu, 19 Sep 2013 13:44:48 +0000
To: Buddy Burden via RT <bug-Method-Signatures@rt.cpan.org>
From: Matt S Trout <mst@shadowcat.co.uk>
On Thu, Sep 19, 2013 at 04:47:42AM -0400, Buddy Burden via RT wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=88716 > >
> > As documented, this is now deprecated in favour of Moo ...
> > Trust me, if it were just a matter of replacing `Any::Moose` with `Moo`, it would be done by now. But the only thing we use Mouse/Moose for is the types, and Moo doesn't really have types. (There's MooX::Types::MooseLike, but it's not really a drop-in replacement.) So we were stuck on how to approach it for a while there.
MooX::Types::MooseLike mirrors MooseX::Types which is best practice. The stupid string type system we don't have a copy of, no, although MooX::late handles it for people porting legacy code.
Show quoted text
> The current thinking, though, is to drop Moose/Mouse altogether and go with Type::Tiny / Types::Standard (see [GitHub #81](https://github.com/schwern/method-signatures/issues/81)). So hopefully I can find the tuits to tackle that very soon.
PR 85 was submitted two months ago to do that - any chance you could comment on there what else is required? -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.
Show quoted text
> MooX::Types::MooseLike mirrors MooseX::Types which is best practice. > > The stupid string type system we don't have a copy of, no, although > MooX::late > handles it for people porting legacy code.
It doesn't mirror the API, though, which is the important bit (for us). And I understand why it doesn't: most people don't need that. No need to add all that extra code for something that only a small percentage of users need. We just happen to be in that small percentage. ;-> Specifically, the only thing we ever do with a type is call the type_check method on it. So, if the type doesn't have one of those, it's not doing us much good.
Show quoted text
> > The current thinking, though, is to drop Moose/Mouse altogether and > > go with Type::Tiny / Types::Standard (see [GitHub > > #81](https://github.com/schwern/method-signatures/issues/81)). So > > hopefully I can find the tuits to tackle that very soon.
Show quoted text
> PR 85 was submitted two months ago to do that - any chance you could > comment > on there what else is required?
The pull request you reference is an outgrowth of the longer discussion I mentioned above (#81). I laid out there pretty clearly what I need to do: performance testing is the first thing, and also compatibility testing (that is, tobyink seems mostly confident that mingling Moose types with Type::Tiny will Just Work(tm), but further testing is warranted). But, if you think a note in #85 referencing back to #81 is helpful for outsiders, I'll go ahead and add that.
On 2013-09-25 11:16:39, BAREFOOT wrote:
Show quoted text
> The pull request you reference is an outgrowth of the longer > discussion I mentioned above (#81). I laid out there pretty clearly > what I need to do: performance testing is the first thing, and also > compatibility testing (that is, tobyink seems mostly confident that > mingling Moose types with Type::Tiny will Just Work(tm), but further > testing is warranted). But, if you think a note in #85 referencing > back to #81 is helpful for outsiders, I'll go ahead and add that.
How is the testing going?
Ping!
On Wed Sep 25 14:16:39 2013, BAREFOOT wrote:
Show quoted text
> It doesn't mirror the API, though, which is the important bit (for > us).
Type::Tiny does. Please switch to that.
On 2015-08-15 18:18:08, MSTROUT wrote:
Show quoted text
> On Wed Sep 25 14:16:39 2013, BAREFOOT wrote:
> > It doesn't mirror the API, though, which is the important bit (for > > us).
> > Type::Tiny does. Please switch to that.
Another year and a half on... is there any hope? Downstream users have noticed issues: https://rt.cpan.org/Ticket/Display.html?id=120203


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

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