undeclare.pl: MooseX::Declare -> Moose
Our current project at my job is based solely on rather sophisticated object model, we've chosen MooseX::Declare as one of our main helpers. We are very happy with compiletime argument checks, I guess it saves us a lot of debugging time.
Unfortunately our app performance was far from satisfying; the profiling showed it was MXD's fault. Also, we found an enlightening benchmark.
The problem was solved by implementing a tool that allowed us to have two variants of our codebase: development and release. Release is prepared by translating method declarations with method signatures into plain perl subs with parameters parsing. This job is done by undeclare.pl, it uses PPI to parse and transform .pm files.
Some of our domain-specific tests now run more than 10 times faster.
The problem was solved by implementing a tool that allowed us to have two variants of our codebase: development and release. Release is prepared by translating method declarations with method signatures into plain perl subs with parameters parsing. This job is done by undeclare.pl, it uses PPI to parse and transform .pm files.
Some of our domain-specific tests now run more than 10 times faster.
I blog about Perl.
> We are very happy with compiletime argument checks
Actually, they're performed at runtime. In fact, MooseX::Declare methods aren't even declared until runtime. If the checks could be performed at compile time, perl wouldn't be perl, Perl wouldn't be Perl, and undeclare.pl wouldn't be necessary :-)
An alternative approach might be to propose a patch for MooseX::Method::Signatures to allow its goodness to be disabled for production e.g. through a $MOOSEX_METHOD_SIGNATURES_DISABLE environment variable.
Couldn't disabling MooseX::Method::Signatures produce funny side effects wrt. type coercion?
--Steffen
Oh, thanks for correcting me. It seems like a bad habit of mine to call it compile time, sure it actually isn't.
I like the idea of being able to change behaviour by adding one line of code in your source. At the moment I don't understand well enough how MXMS and MXD do their job, so I can't see the way one can implement such behaviour switch without applying a source filter. Now I can imagine only something similar to undeclare.pl being applied behind the scene when $MOOSEX_METHOD_SIGNATURES_DISABLE is true.
I've recently come across a statement (haven't checked it myself yet) that
MooseX::Params::Validate is faster than MXMS. It is possible to improve undeclare.pl and make use of MooseX::Params::Validate for type coercion.
By the way, the only purpose we used type coercion for was auto-creating our UUID objects from strings, but later we switched to plain strings for performance gain.
Type coercion is great to get rid of boilerplate code when dealing with modules written by other people, but if you control API you have to use it is possible to go with some strict and clean design.
> Couldn't disabling MooseX::Method::Signatures produce funny side
> effects wrt. type coercion?
Yes, and defaults would have to be preserved as well. That's what would make the patch such fun to work on :-)
Yesterday I updated undeclare.pl at github. Defaults are preserved now.
A rather dull benchmark of MooseX::Params::Validate compared to methods and plain subs.