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: 52336
Status: open
Priority: 0/
Queue: Mouse

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

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



Subject: Friendlier guts for tweaking
Download (untitled) / with headers
text/plain 1.4k
Hello, Mouse is a nice alternative to Moose, but it would be even better if some of the initialization guts were a little cleaner. I'm playing with Package::Alias to allow the end user to alias Moose to Mouse, for a more transparent substitution. This way it doesn't matter if any 3rd party code uses Moose instead of Any::Moose, Mouse is what everything gets. Unfortunately, because %Mouse::Exporter::SPEC is used to check callers, and it is my instead of our, to get this to work the end-user has to call Mouse::Exporter->setup_import_methods. And because setup_import_methods doesn't contain the defaults, but Mouse does, One ends up with a rather bulky initialization: BEGIN{ use Package::Alias Moose => Mouse; Moose::Exporter->setup_import_methods(exporting_package=>'Moose', as_is => [qw( extends with has before after around override super augment inner ), \&Scalar::Util::blessed, \&Carp::confess, ], ); } versus: use Moose; or use Package::Alias Moose => Mouse; Or perhaps you'd be interested in updating Any::Moose to pull in the necessary magic to permit this more user-friendly configuration? package main; #use Any::Moose; #Fallback to whichever use Any::Moose preferred=>Mouse; #Try to force Mouse use Frogs; ... package Frogs; use Moose; #Frog is a Mouse See https://rt.cpan.org/Ticket/Display.html?id=52314
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Wed, 2 Dec 2009 01:08:21 +0200
To: bug-Mouse [...] rt.cpan.org
From: Yuval Kogman <nuffin [...] cpan.org>
Download (untitled) / with headers
text/plain 213b
That can only work in the other direction, since many Moose using modules need the extra features in Moose and can't work directly on Mouse (whereas code that works on Mouse is expected to work cleanly on Moose).
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Tue, 01 Dec 2009 18:13:38 -0500
To: bug-Mouse [...] rt.cpan.org
From: Jerrad Pierce <belg4mit [...] pthbb.org>
Download (untitled) / with headers
text/plain 928b
Show quoted text
>That can only work in the other direction, since many Moose using modules >need the extra features in Moose and can't work directly on Mouse (whereas >code that works on Mouse is expected to work cleanly on Moose).
Not at all. You are assuming that people use Moose because they need all of its features and heft. I am assuming most people use Moose because they don't know about Mouse or Any::Moose. Therefore, the *end user* should have the ability to force code to use Mouse if they want. If it blows up because Mouse is missing something, they'll know not to force it. If it works as expected (which seems the more probable case), they've saved themselves from being gored by giant antlers :-P -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 43rd of The Aftermath, in the YOLD 3175: It is wildly, crazily, stupidly, cross-eyed-blithering-insectly wrong! --DNA
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Wed, 2 Dec 2009 01:25:52 +0200
To: bug-Mouse [...] rt.cpan.org
From: Yuval Kogman <nuffin [...] cpan.org>
Download (untitled) / with headers
text/plain 1.1k
You're assuming that breakage will be self evident and immediate, which is usually not the case (typically incompatibilities are due to runtime introspection facilities that are missing in Mouse). Secondly, the end user should just alias the package themselves, Any::Moose is the wrong place for it. Any::Moose is specifically designed to be generally safe (though it still fails quite badly, for instance when trying to extend an Any::Moose class with plain Moose and running into load order issues that may cause action at a distance by causing the Any::Moose class to be Mouse based before Moose was actually loaded). Anyway, my point is that therein lies lots of potential brain damage for a future maintenance programmer. I don't think it's a good idea to add that to something that is designed to be low impact. This is more of a MooseX::Hijack::WithMouse or something like that, it should be clear that it's an invasive change, that you can easily add as a -M option to perl, or whatever. Putting this type of change in Any::Moose directly will just lead modules that modify global values being uploaded to the CPAN IMHO.
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Wed, 02 Dec 2009 02:44:25 -0500
To: bug-Mouse [...] rt.cpan.org
From: Jerrad Pierce <belg4mit [...] pthbb.org>
Download (untitled) / with headers
text/plain 452b
Okay, I understand. I'd still tend to go the other way, and have provided a simple "Any::Moose::Forcefully" on the advent calendar's entry about Mouse: http://www.perladvent.org/2009/1/ Cheers! -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 44th of The Aftermath, in the YOLD 3175: sex, drugs, rock & roll chips, dips, chains, whips you know, you're basic highschool orgy kind of thing
Download (untitled) / with headers
text/plain 446b
Wow, that post is FULL of inaccuracies and doc misreadings, please either remove it or fix it. It is fine if you want to promote Mouse, but please get your facts straight. - Stevan On Wed Dec 02 02:44:54 2009, belg4mit@pthbb.org wrote: Show quoted text
> Okay, I understand. I'd still tend to go the other way, and have provided > a simple "Any::Moose::Forcefully" on the advent calendar's entry about > Mouse: http://www.perladvent.org/2009/1/ > > Cheers!
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Wed, 02 Dec 2009 16:54:08 -0500
To: bug-Mouse [...] rt.cpan.org
From: Jerrad Pierce <belg4mit [...] pthbb.org>
Download (untitled) / with headers
text/plain 622b
Show quoted text
>Wow, that post is FULL of inaccuracies and doc misreadings, please either >remove it or fix it. It is fine if you want to promote Mouse, but please >get your facts straight.
What a helpful response. Thankfully Mr. Trout provided explicit details about the misunderstnadings and short-comings of the initial draft. The entry has since been updated to address them. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 44th of The Aftermath, in the YOLD 3175: sex, drugs, rock & roll chips, dips, chains, whips you know, you're basic highschool orgy kind of thing
Download (untitled) / with headers
text/plain 1.9k
On Wed Dec 02 16:54:23 2009, belg4mit@pthbb.org wrote: Show quoted text
> >Wow, that post is FULL of inaccuracies and doc misreadings, please either > >remove it or fix it. It is fine if you want to promote Mouse, but please > >get your facts straight.
> What a helpful response. Thankfully Mr. Trout provided explicit details > about the misunderstnadings and short-comings of the initial draft. > The entry has since been updated to address them.
I know, I saw matt's email before I wrote this so I knew he supplied you with details I just wanted to put in my 2 cents. I am still not 100% sure you have your facts straight. I don't think that Mouse "starts-up 4 times faster than Moose", in fact a quick check on my machine shows that it is actually closer to 5 times faster in startup (4.75 if you wanna be picky). stevan% /usr/bin/time perl -MMoose -e 1 0.19 real 0.17 user 0.02 sys stevan% /usr/bin/time perl -MMouse -e 1 0.04 real 0.03 user 0.00 sys I would also disagree with your comment about Mouse implementing a subset of the "more superficial and sexier features". Many people find the MOP to be a very sexy feature and Mouse only has very limited support for that. However this is trivial and your newest update to add the paragraph about the metaprotocol stuff being the "raison d'être of Moose" is fine by me. I am sorry if you feel attacked by us (the Moose community) however you have to understand that your post was somewhat on the inflammatory side. While we do discourage use of Mouse, we have no problem with people using Mouse if they want or need too. Your post though was advocating a rather aggressive method of altering other peoples code in ways that could be considered evil and at the very least invasive. We also know pretty well (from experience with Squirrel and then Any::Moose) that this technique will probably only work with the simplest of Moose modules and so tends to lead people to run into a lot of very hard to debug problems. - Stevan
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Wed, 02 Dec 2009 17:59:37 -0500
To: bug-Mouse [...] rt.cpan.org
From: Jerrad Pierce <belg4mit [...] pthbb.org>
Download (untitled) / with headers
text/plain 2.7k
Show quoted text
>I know, I saw matt's email before I wrote this so I knew he supplied you with >details I just wanted to put in my 2
Okay, sorry. I didn't check the date stamps, and it looked like your message had been first but lost in the shuffle. Show quoted text
>I am still not 100% sure you have your facts straight. I don't think that >Mouse "starts-up 4 times faster than Moose", in fact a quick check on my >machine shows that it is actually closer to 5 times faster in startup >(4.75 if you wanna be picky).
4x are what the docs say, if one is able to parse that sentence as it was apparently intended (though I did not initially). Having various other time constraints, I didn't have a chance to test it myself, though we usually try to. If someone is interested in verifying those figures, Test::Aggregate could be helpful in accurately doing so. If Mouse's gains really are all in start-up, the disparity between run times of Mo[ou]se with a common test-suite should largely disappear. Show quoted text
>I am sorry if you feel attacked by us (the Moose community) however you have >to understand that your post was somewhat on the inflammatory side. While we >do discourage use of Mouse, we have no problem with people using Mouse if they >want or need too. Your post though was advocating a rather aggress ive method >of altering other peoples code in ways that could be considered evil and at >the very least invasive. We also know pretty well (from experience with
I suppose it can be seen that way, but it was meant in the light of giving power back to the end user, who ultimately has the right to do what they please with the code they choose to run. Indeed, someone else has commented to me that with the ability to forcibly use Mouse, they may be able to adopt the general OO framework of Mo[ou]se "ten years earlier;" they work for a large and very conservative business. Perhaps a bit of an exaggeration, but the general idea remains. It's easier to concvince the powers that be to review/test/install a single, smaller module than a dozen that are twice the size. Might they occasionally run into problems with code that was written against Moose? Sure, but at least they have the option of using those that don't but still say "use Moose" rather than "use Any::Moose" without waiting for them to be patched, or developing their own packages. Or, with it's foot in the door, Moose would have a leg-up on being accepted to address Mouse's shortcomings. In any event, I'm glad things are more less settled, and I can move on to more pressing matters. Sincerely, Jerrad Pierce -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 44th of The Aftermath, in the YOLD 3175: sex, drugs, rock & roll chips, dips, chains, whips you know, you're basic highschool orgy kind of thing
Subject: Re: [rt.cpan.org #52336] Friendlier guts for tweaking
Date: Wed, 2 Dec 2009 18:12:26 -0500
To: Goro Fuji via RT <bug-Mouse [...] rt.cpan.org>
From: Stevan Little <stevan.little [...] iinteractive.com>
Download (untitled) / with headers
text/plain 4.1k
On Dec 2, 2009, at 6:00 PM, belg4mit@pthbb.org via RT wrote: Show quoted text
> Queue: Mouse > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=52336 > >
>> I know, I saw matt's email before I wrote this so I knew he >> supplied you with >> details I just wanted to put in my 2
> Okay, sorry. I didn't check the date stamps, and it looked like your > message > had been first but lost in the shuffle. >
>> I am still not 100% sure you have your facts straight. I don't >> think that >> Mouse "starts-up 4 times faster than Moose", in fact a quick check >> on my >> machine shows that it is actually closer to 5 times faster in startup >> (4.75 if you wanna be picky).
> 4x are what the docs say, if one is able to parse that sentence as it > was apparently intended (though I did not initially).
Speed of test suite run is approx 4 time faster, speed of raw startup looked closer to 5, maybe 6 depending how how you read the output. Show quoted text
> Having various other time constraints, I didn't have a chance to > test it > myself, though we usually try to. If someone is interested in > verifying those > figures, Test::Aggregate could be helpful in accurately doing so. If > Mouse's > gains really are all in start-up, the disparity between run times of > Mo[ou]se > with a common test-suite should largely disappear.
Moose has issues with Test::Aggregate so this wouldn't really help (we re-use Foo as package name in the tests too often). I suspect Mouse would have the same issue too. Show quoted text
>> I am sorry if you feel attacked by us (the Moose community) however >> you have >> to understand that your post was somewhat on the inflammatory side. >> While we >> do discourage use of Mouse, we have no problem with people using >> Mouse if they >> want or need too. Your post though was advocating a rather aggress >> ive method >> of altering other peoples code in ways that could be considered >> evil and at >> the very least invasive. We also know pretty well (from experience >> with
> I suppose it can be seen that way, but it was meant in the light of > giving > power back to the end user, who ultimately has the right to do what > they > please with the code they choose to run. > > Indeed, someone else has commented to me that with the ability to > forcibly use > Mouse, they may be able to adopt the general OO framework of Mo[ou]se > "ten years earlier;" they work for a large and very conservative > business. > Perhaps a bit of an exaggeration, but the general idea remains. It's > easier > to concvince the powers that be to review/test/install a single, > smaller > module than a dozen that are twice the size. > > Might they occasionally run into problems with code that was written > against > Moose? Sure, but at least they have the option of using those that > don't but > still say "use Moose" rather than "use Any::Moose" without waiting > for them > to be patched, or developing their own packages. Or, with it's foot > in the > door, Moose would have a leg-up on being accepted to address Mouse's > shortcomings.
I guess what I am trying to say is that you will find only a handful of all the Moose based modules that don't also use MooseX:: modules with no equivalent MouseX:: (which btw your code doesn't even address) or some of the MOP features not supported in Mouse (it happens more often then you might think). And even if it works today, if the module author made changes that didn't work with Mouse this could cause really ugly issues (and probably a few really confusing bug reports). As for helping bigger companies adopt Moose, well, I worry that this type of invasive technique would actually hurt in the long run because when things go bad (and I am sure they will at some point) it would look bad for Moose. Show quoted text
> In any event, I'm glad things are more less settled, and I can move > on to more > pressing matters.
Sure, I am fine with leaving this where it is, just know (and I mean this with no disrespect to you) we will likely discourage this technique for anyone who comes looking for help after adopting this technique. It is clever, but fragile, we know we have already been there and seen the issues. - Stevan


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.