Re: Any gotchas with CGI and Mouse running together?

No real gotchas. I prefer Moo to Mouse/Moose. I think the defaults are better and things like inline “type” checking more Perlish; more self-documenting; easier to remember.

Mouse is much faster than the other meta-OO options. So, if this were my project the choice between Moo and Mouse would boil down to the execution. If the app is persistently executed, I’d pick Moo, otherwise, Mouse. If it’s persistent then you should be looking at running/harnessing it as PSGI too, whether or not the base code is in CGI.

…Then again, some casual tests on the command line suggest the start-up speed of Moo is only 0.001s slower than Mouse so maybe Moo anyway depending on how many objects and how much access you’re wrangling. I have also had far fewer cross compat/build/deps problems with Moo than Mouse or Moose, FWIW; in a very static env this shouldn’t matter though.

Comment on Re: Any gotchas with CGI and Mouse running together?

Replies are listed 'Best First'.
Re^2: Any gotchas with CGI and Mouse running together? by kcott (Archbishop) on Feb 27, 2015 at 03:13 UTC
++ Thanks for this excellent answer: good information on both Moo and PSGI. -- Ken	[reply]
Re^2: Any gotchas with CGI and Mouse running together? by LanX (Saint) on Feb 27, 2015 at 02:46 UTC
> the start-up speed Maybe a silly question, but if start-up speed is so significant why isn't there a precompiled version of Moose? Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)} PS: Je suis Charlie!	[reply]
Re^3: Any gotchas with CGI and Mouse running together? by Your Mother (Archbishop) on Feb 27, 2015 at 03:57 UTC
I don’t think it’s silly. The Mouse is precompiled essentially being XS (when built with it). I expected it to be faster actually but regular old Perl often surprises me with how fast it is. I tend to forget that most of why stuff at work is slow is awful DB code and not just the awful Perl we have. :P Doing thousands of objects and methods would probably make the Mouse a clear winner. So it would depend on how big/complex the code chains will end up. Start up time is only a (serious) issue if running plain CGI as executables; which is a terrible way to do things but still the easiest. Our codebase at work is 50% legacy CGI that was finally taking 3 seconds to return simple pages—code bloat and universal loading of all the libs we have. Making it persistent (pre-compiled by a master server) fixed (most of the outward perception of) that.	[reply]
Re^4: Any gotchas with CGI and Mouse running together? by LanX (Saint) on Feb 27, 2015 at 04:30 UTC
Thx, already up-voted after the first phrase! ;) But let me rephrase: for various reasons I never got sufficiently well into any of those `/M[eosu]+\.pm/` animals. I always read that even a simple use case of Moose has a notable startup penalty, but its not applying Moose to create objects and classes which is slow. Hence should Moose itself have a costly compilation/ BEGIN phase when used. At the same time perlcc is praised for its ability to precompile code to a static OP-tree. So either it should be possible to precompile Moose to fast OP-code-image or something is wrong in my understanding. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)} PS: Je suis Charlie!	[reply] [d/l]
Re^5: Any gotchas with CGI and Mouse running together? by Your Mother (Archbishop) on Feb 27, 2015 at 18:03 UTC
Re^6: Any gotchas with CGI and Mouse running together? by LanX (Saint) on Feb 27, 2015 at 18:17 UTC
Some notes below your chosen depth have not been shown here


Clear questions and runnable code get the best and fastest answer
	PerlMonks