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