Dynamic role application could cause problems (?)
Here is a RT ticket to Mouse: https://rt.cpan.org/Public/Bug/Display.html?id=61312 Applying roles after the fact changes the flow of method modifiers. It seems that application order takes precedence over the actual modifier type. This issue he reported occurs not only on Mouse, but also on Moose. Is this really a problem? We should resolve it? -- Fuji, Goro (藤 吾郎)
Re: Dynamic role application could cause problems (?)
On Tue, 14 Sep 2010 20:45:55 +0900, Fuji, Goro g.psy...@gmail.com wrote: Here is a RT ticket to Mouse: https://rt.cpan.org/Public/Bug/Display.html?id=61312 Applying roles after the fact changes the flow of method modifiers. It seems that application order takes precedence over the actual modifier type. This issue he reported occurs not only on Mouse, but also on Moose. Is this really a problem? We should resolve it? It's such longstanding behavior that even if we wanted to change it now (and while there are definitely arguments in favor of it, I think stevan argues against it every time it comes up), I think we'd have a really hard time doing so. hdp.
Re: Dynamic role application could cause problems (?)
- Original Message From: Fuji, Goro g.psy...@gmail.com Here is a RT ticket to Mouse: https://rt.cpan.org/Public/Bug/Display.html?id=61312 Applying roles after the fact changes the flow of method modifiers. It seems that application order takes precedence over the actual modifier type. This issue he reported occurs not only on Mouse, but also on Moose. Is this really a problem? We should resolve it? In the original traits papers, it was thought that roles would only provide pure methods and not have access to state. They later realized that this was a mistake and admit that accessing state is important. However, method modifiers makes this a bit tricky as you've noted. In fact, method modifiers open up a whole can o' worms, particularly when you're applying roles at runtime. There's a simple way of dealing with this: assume that as a matter of good style, method modifiers can access state, but not alter it. Otherwise, it's as bad as diddling global variables and leads to the same sort of maintenance nightmares. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Dynamic role application could cause problems (?)
On Sep 14, 2010, at 9:15 AM, Ovid wrote: - Original Message From: Fuji, Goro g.psy...@gmail.com Here is a RT ticket to Mouse: https://rt.cpan.org/Public/Bug/Display.html?id=61312 Applying roles after the fact changes the flow of method modifiers. It seems that application order takes precedence over the actual modifier type. This issue he reported occurs not only on Mouse, but also on Moose. Is this really a problem? We should resolve it? In the original traits papers, it was thought that roles would only provide pure methods and not have access to state. They later realized that this was a mistake and admit that accessing state is important. However, method modifiers makes this a bit tricky as you've noted. In fact, method modifiers open up a whole can o' worms, particularly when you're applying roles at runtime. I totally agree, and if I had to do it over again, I would not have allowed method modifiers in roles. They ruin the unordered-ness of roles and bring about edge cases like this that are not so easily solved. - Stevan
Re: Supress Moose warnings
I wasn't aware of this module. It worked like a charm! Thanks! On Tue, Sep 14, 2010 at 2:15 PM, Karen Etheridge p...@froods.org wrote: On Tue, Sep 14, 2010 at 02:05:29PM -0400, Marcos Barbeitos wrote: Hi! I just started using Moose in this project I've been working on. I am preparing a test suite and I'd like to test if type checking was effectively implemented in a couple of modules. In order to do that, some of the tests actually cause Moose to die, but Moose won't go silently and the long stack backtrace clutters the test suite output. Is there anyway of suppressing the warnings? I tried to set $Carp::Verbose to 0 in the package I wrote with Moose, to no avail. Thanks! Are you capturing the errors it is producing when it dies? If so, it shouldn't be cluttering the rest of your tests.. see dies_ok and throws_ok in Test::Exception. -- I choose to see your feelings of powerlessness as a choice because I need to believe in free will to assuage my guilt over my absurdly luxurious lifestyle. - suck.com . . . . . Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-) -- Marcos S. Barbeitos Post-doctoral researcher American Museum of Natural History Department of Invertebrate Zoology 79th st and Central Park West New York, NY 10024
Re: Supress Moose warnings
If it is actually warnings that you want to suppress, then Adam Kennedy's Test::NoWarnings module may help you. It is used somewhere by the DBD::SQLite test suite, which is how I know about it. -- Darren Duncan
