When you define a type, you typically only specify how the type differs from some parent type. Currently, as a way to speed up type constraint checking, you can use the optimize_as option to define a validation subroutine to be used in place of checking the parent constraint followed by the current constraint's check. This helps, but could be better.
In 2.02, you will be able to use the inline_as option instead, to define a code snippet to use when inlining this type constraint, avoiding even the subroutine call overhead in accessors and constructors. Based on some simple benchmarks, this speeds up accessors by 30-40% and constructors by 10-30%, depending on the type constraints used and what else the methods are doing:
Moose 2.00 ------ Benchmark: timing 500000 iterations of accessors_simple, constructor_simple... accessors_simple: 4 wallclock secs ( 4.41 usr + 0.00 sys = 4.41 CPU) @ 113378.68/s (n=500000) constructor_simple: 18 wallclock secs (17.83 usr + 0.01 sys = 17.84 CPU) @ 28026.91/s (n=500000) Benchmark: timing 20000 iterations of accessors_all, constructor_all... accessors_all: 12 wallclock secs (11.92 usr + 0.01 sys = 11.93 CPU) @ 1676.45/s (n=20000) constructor_all: 12 wallclock secs (11.85 usr + 0.01 sys = 11.86 CPU) @ 1686.34/s (n=20000) Moose 2.02 ----- Benchmark: timing 500000 iterations of accessors_simple, constructor_simple... accessors_simple: 3 wallclock secs ( 2.70 usr + 0.01 sys = 2.71 CPU) @ 184501.85/s (n=500000) constructor_simple: 15 wallclock secs (16.15 usr + 0.00 sys = 16.15 CPU) @ 30959.75/s (n=500000) Benchmark: timing 20000 iterations of accessors_all, constructor_all... accessors_all: 8 wallclock secs ( 7.45 usr + 0.01 sys = 7.46 CPU) @ 2680.97/s (n=20000) constructor_all: 8 wallclock secs ( 7.73 usr + 0.01 sys = 7.74 CPU) @ 2583.98/s (n=20000)
Because inline_as provides all of the functionality that optimize_as provided, optimize_as will be deprecated in 2.02, and eventually removed.
Constructors and accessors are generated as closures. For instance, when you pass "default => sub { ... }" as an attribute option, that sub is saved, and then closed over when the accessor is generated (if the attribute is lazy), something along the lines of:
my $default = $attr->default;
my $code = eval "sub { ... }"; # this uses $default
$meta->add_method($attr->name => $code);
Previously, we used to close over a lot of meta-objects directly, out of convenience, but this makes deparsing hard because of the many links metaobjects have between each other (try using Data::Dump::Streamer to deparse a Moose-generated constructor!). More importantly though, this gets in the way of some future optimizations we're hoping to be able to do.
The actual effects of this are mostly only visible if you're writing extensions that require using the closed-over variables that were removed ($attr, $meta, $type_constraint_obj, etc). If you were, you'll have to either adjust your inlining code to use the new variables that are provided, or override the environment that Moose uses when compiling generated methods to add them back. Feel free to stop by #moose if you have questions about how to do this.
Finally, one obstacle to this being complete is that initializer subs receive the attribute metaobject as a parameter, which means we can't avoid closing over it in that case. This behavior is now deprecated, and will be removed in the future.
Please install the current release candidate (Moose 2.0102) from CPAN, and report any issues it causes with your code. If all goes well, Moose 2.0200 will be released on July 18.
]]>Join us for an interactive hands-on course all about Moose, an OO system for Perl 5 that provides a simple declarative layer of "sugar" on top of a powerful, extensible meta-model.
With Moose, simple classes can be created without writing any subroutines, and complex classes can be simplified. Moose's features include a powerful attribute declaration system, type constraints and coercions, method modifiers ("before", "after", and "around"), a role system (like mixins on steroids), and more. Moose also has a vibrant ecosystem of extensions as seen in the variety of MooseX:: modules on CPAN.
This course will cover Moose's core features, dip a toe into the meta-model, and explore some of the more powerful MooseX:: modules available on CPAN.
Students are expected to bring a laptop, as you will be writing code during the class. You will also be provided with a tarball a week or so before the class is scheduled, which will contain a directory tree skeleton and test files.
]]>MooseX modules whic affect attributes, like MooseX::SemiAffordanceAccessor and MooseX::LazyRequire, now have different behavior in conjunction with roles.
When you use one of these modules in your class, it applies a trait to all of the attributes defined in your class:
package MyClass;
use Moose;
use MooseX::SemiAffordanceAccessor;
has foo => ( is => 'rw' );
In this example, the foo attribute ends up with the
MooseX::SemiAffordanceAccessor::Role::Attribute trait applied to it behind
the scenes. This trait is what affects how accessors are named.
With the current version of Moose, these attribute traits are also applied to attributes provided by roles:
package MyClass;
use Moose;
use MooseX::SemiAffordanceAccessor;
with 'MyRole';
has foo => ( is => 'rw' );
Any attributes provided by MyRole end up with the SemiAffordanceAccessor
naming scheme.
This is a huge stinking bug. The problem is that by applying this trait, we
have changed the interface provided by MyRole. One of the major uses of
roles is to provide a named interface, so this is bad.
With Moose 2.0, this bug is fixed. When we apply MyRole, the attributes
applied from the role no longer acquire the attribute traits of the consuming
class.
However, some people might have been taking advantage of this feature, writing roles with the assumption that the consuming class uses a MooseX module.
The right thing to do is to use the relevant MooseX module in the role itself. This is not possible with Moose 1.2x, but will be possible in Moose 2.0. The only catch is that the MooseX module has to explicitly support this.
For many modules, this is trivial. Let's take MooseX::SemiAffordanceAccessor
as an example. The code used to look like this:
Moose::Exporter->setup_import_methods(
class_metaroles => {
attribute => ['MooseX::SemiAffordanceAccessor::Role::Attribute'],
},
);
To make it work with both new and old Moose, it becomes:
my %metaroles = (
class_metaroles => {
attribute => ['MooseX::SemiAffordanceAccessor::Role::Attribute'],
},
);
$metaroles{role_metaroles} = {
applied_attribute => ['MooseX::SemiAffordanceAccessor::Role::Attribute'],
} if $Moose::VERSION >= 1.9900;
Moose::Exporter->setup_import_methods(%metaroles);
Some MooseX modules don't have it so easy. If your MooseX applies traits to the class metaclass as well as the attributes, making it work with roles is much harder. We're planning to make this simpler in Moose 2.02, but for now your best bet is to look at a module like MooseX::Attribute::Deflator for an example of how to do this. Basically, you have to have the role "pass along" the class metaroles when the role is applied.
As a consumer of a MooseX module, updating to Moose 2.0 will be fairly simple. If you want to apply a MooseX module to attributes in role, just use the module in your roles.
We're currently working with MooseX authors to get their modules updated in preparation for the Moose 2.0 release.
We're available on irc://irc.perl.org/#moose-dev to help you update your module, or you can email us at moose@perl.org. Please contact us if you need help updating your code.
]]>Note, though, that calling Moose "the preferred OO framework" is a bit of puffery. Some people prefer it, but I'll bet you most Perlers have never even looked at it. Not only that, the fragmentation of Mouse, Moose, Moo, and whatever else out there is starting to confuse people who haven't started yet (so it's a frequent question I get).
Of course from inside the Modern Perl/Moose bubble it is hard to believe that people haven't heard of Moose. And while I do think Moose is seeping out more and more, brian, with his unique position of being a well known figure both inside and outside of the Perl community, is very much right about the confusion over Moose, Mouse, Moo, et al. So after much discussion with the other core Moose team I decided it was time to write a blog post to help clear things up.
So of course we (the core Moose devs) believe that Moose is the best choice, but we are not so ignorant as to believe that Moose is the right choice for everyone and every environment. And it was this exact reason that brought about Mouse and which is currently driving the Moo effort. Additionally Moose has always tried it's best to not make you pay for features you don't use by doing things like compiling highly focused accessors and lazy loading features when possible, which, when taken to the extreme leads to modules like Class::Method::Modifiers and Role::Basic in which Moose features are extracted completely.
So how does all this fit into the Moose ecosystem??
So as I said, we think Moose is the best choice, but when Moose is prohibitive, either because of startup overhead or memory usage, then Mouse is currently the best choice and one we encourage. Period.
In reality, there is no fragementation here because Mouse is very much commited to maintaining surface Moose compatability and runs a fair portion of the Moose test suite successfully (minus the Meta-Object tests of course).
Additionally tools like Any::Moose allow you to defer your decision and/or provide both options when possible. There have even been a few MooseX:: modules ported to MouseX and while this practice is generally discouraged because there are simply too many moving parts to keep in sync, the need existed and so people obliged.
In the end, what is important for us is that people are writing good OO code following the guidelines that Moose encourages. If, for whatever reason, they need to use Mouse to do that, it is okay with us. At least for now that is ...
Ever since the early days of Moose we have been searching for ways to make Moose startup time faster. Recent heavy profiling by core Moose devs, Jesse Luehrs and Dave Rolsky, has lead to some pretty hefty speed-ups and plans for even more in the future. But we know that there is only so far this path can take us.
And then we come to mst and Moo.
Moo is an experiment from the sick and twisted mind of mst to radically re-think how Moose goes about compiling all it's meta objects. It builds on ideas from even more experimental MooseX::Compile born from the equally twisted mind of Yuval Kogman and an earlier mst experiment called MooseX::Antlers.
While mst and a few other brave souls are actually using Moo successfully, it is currently only in very limited situations with very simple "baby" Moose code. And really in the end, if Moo succeeds, you won't even know it is there because it will just be part of how Moose does it's thing. It is at this point that the community may choose to deprecate Mouse, but we will cross that bridge when we come to it.
So again, no real fragmentation here either, it is all part of the grand plan.
The Perl community has long prided itself as being an group of independent minded (cough stubborn cough) people who don't just jump on the shiniest bandwagon or take the easy way out. We are well aware that Moose is a lot of Kool-Aid to drink and is not the right choice for everyone. And obviously because of this Mouse is not useful to these people either. So this is where some of the Moose inspired modules come into play.
In some cases these modules are re-implementations of Moose features, in other cases they are parts of Moose that have been extracted because of their usefulness to others outside of Moose. Here is a short, totally noncomprehensive list ...
As we said above, the ultimate goal of Moose has always been to make writing good OO code in Perl a less tedious and repetitive process. While we think Moose is the best way to do that, it is understandable that sometimes you only need a small part of it and all these modules provide this. And really as long as they maintain some level of commitment to Moose compatability, this works for us because it still serves our ultimate goal.
So sure, a little fragmentation here, but with a compatability commitment these really just become gateway modules to Moose.
And lastly, I wanted to touch on the number of modules that have been in some way inspired by or related to Moose development. This subject really deserves it's own blog post, but I think it is worth mentioning these modules.
So hopefully this helps clear up some of the confusion that brian has seen on his adventures outside of the Modern Perl bubble. One of the really interesting and beautiful things about Open Source software development and the CPAN community in particular is that it really is a true meritocracy and functions extremely well as highly organized chaos. The drawback to that is that sometimes we have to clear up some confusion like this, which when viewed against the benefits is not that bad at all.
Happy New Year!
]]>Now, on to the fun part(: The next Moose release will contain several exciting new improvements, both for users and extension authors. The first is that there has been a significant effort to speed up Moose's compilation time, through several means. The largest and most obvious is that Package::Stash, the module that Moose uses to do its symbol table manipulation (for adding and retrieving methods, among other things), has been rewritten entirely in XS. Since Moose spends over a third of its compilation time doing symbol table manipulation, this seemed like a good optimization target, and this turns out to have been correct - it resulted in a 10-15% speedup across the board for Moose application compile times. Another advantage to this is that it fixes a couple (admittedly minor) long-standing bugs in the Class::MOP::Package API, since the symbol table API available from pure perl has several inherent issues itself. Another area that should see significant improvement is in code which uses the native delegation attribute traits. Previously (ever since the rewrite in 1.15), the traits themselves were loaded lazily (i.e. Moose::Meta::Attribute::Native::Trait::Bool wasn't loaded unless you actually declared an attribute with traits => ['Bool']), but the implementations of each native delegation were all loaded at once, when the trait itself was loaded. This has been fixed, and should be another fairly large speedup for applications which use only a couple native delegations from the traits they use (which is the case the vast majority of the time). Finally, the way method metaobjects are cached has been improved, which speeds up the introspection of methods (which happens frequently during compilation) a small but noticeable amount. Here are some links to some relevant profiling data (run on my netbook under full profiling, which is why the times are so high): "perl -MKiokuDB -e1" with Moose 1.19: 8.60s, "perl -MKiokuDB -e1" with Moose git: 6.38s, "perl -MMarkdent::Simple::Document -e1" with Moose 1.19: 13.9s, "perl -MMarkdent::Simple::Document -e1" with Moose git: 10.6s. These changes should have minimal compatibility impact (and none at all if you don't use the Class::MOP::Package API); a more detailed discussion is in Moose::Manual::Delta.
In terms of features, we have made a fairly significant change to how attribute metaroles work. Previously, when a role was applied to a class, it would copy the attributes from the role into the class using the class's default attribute metaclass, prior to applying the traits specified in the attribute definition. This is obviously incorrect with a bit of thought - attribute metaclasses completely define how the attribute works, including things like how accessors are generated. If a role contains an attribute and some methods, those methods need to be able to know what method name the accessor is going to be installed under, or the role won't work. A good example of this is a class which uses MooseX::FollowPBP consuming a role which doesn't - currently, this completely breaks the role. With this change, roles now have their own default attribute metaclass, separate from any class. This also allows for an additional feature - when writing extensions, you can specify the 'applied_attribute' option to the 'role' block in 'apply_metaroles' to specify a set of default traits that all attributes defined in that role will receive when they are applied to a class. This should work identically to the 'attribute' option in the 'class' block, and should allow extensions which add default attribute metaroles (such as MooseX::Aliases) to work identically in both classes and roles (unlike currently, where the trait must be applied explicitly in role attributes). The downside to this is that it breaks backwards compatibility in a potentially confusing way: if you were assuming and relying on role attributes using the class's attribute metaclass, your roles will break, and there isn't really a way to detect this. The solution will be to use the same extensions in your roles that you do in the classes that consume those roles, but as noted previously, attribute metaroles don't currently work in roles. These extensions will be fixed by the time we make an actual release.
Finally, there is also some good news for extension authors: the inlining API should be much more sane, and the code itself should be much more readable, so adding inlined method generation support to your modules which affect accessor or constructor/destructor generation should be much, much easier now. Some highlights include: the attribute metaclass and class metaclass controlling entirely how the bodies of the methods they generate are created (so there should no longer be a need to write accessor or constructor metaclass traits), accessor generation in Class::MOP and Moose going through one much simplified codepath (read: removed the obscene amount of code duplication between Class::MOP and Moose), so figuring out how a given accessor is generated should be pretty trivial now, and constructors now asking the attribute metaclass how to initialize attributes at construction time, rather than doing it themselves with a bunch of duplicated code (so in the case of simple attribute traits which affect accessor generation, manually modifying the constructor generation shouldn't even be necessary). The downside to this is, as you may have guessed, the API for doing code inlining has been changed pretty radically. This will require some work on the part of extension authors, in order to use the new API (since there's not really a non-insane way to support both APIs), but again, we'll be working with extension authors to make sure this happens before our actual release, and we'll be releasing a few dev releases prior to the actual release to allow people with non-CPAN code to have a chance to update their code.
As far as a plan goes, we're looking to have our first trial release out by the end of this month, and are aiming for the actual release to happen sometime in late December or early January. If you have any questions about the new release and support process, or about any of these new features, definitely let us know - we're very open to feedback, either here, on the Moose mailing list, or on #moose-dev on IRC.
]]>This release also fixes some random older bugs that have been lingering in rt.cpan for a while.
Finally, this release moves Moose and all of its prereqs from Test::Exception to Test::Fatal. Test::Exception depends on Sub::Uplevel, a module that tends to break with changes in the Perl core. This should make Moose a little more robust against future core changes.
Among the bigger changes ...
Array->join. Oops, that was wrong.You can take a look at Changes in git while the release makes its way to CPAN.
If you're using 1.15, you should probably upgrade to 1.16. If you're on an earlier version, you should consider upgrading too. As always, please test your code with the new Moose.
]]>Native trait delegations are now turned into inline code, just like regular attributes. What this means is that Moose actually generates Perl code when your class loads and then evals it.
The upside is that this makes native trait delegations faster, potentially much faster. With previous versions of Moose, if you defined a native trait as ro or bare, then you could easily end up with a pathologically slow case for delegation.
With the latest Moose, all code is inlined to use direct slot access, which is much faster.
As a bonus, native trait attributes now act more correctly. Constraints are always checked when the value of the attribute changes, and triggers are also fired.
The downside of more code generation is that this makes the compile time a little slower (in direct proportion to how many native delegations you use).
We've also made it possible to prevent Moose from adding a meta method to your class. This is handy for classes which are inheritng from a non-Moose parent (like Rose::DB::Object) that also defines a meta method.
That's the highlights of 1.15. Some of these changes (like checking constraints properly for native traits) could break existing code. Please make sure to read Moose::Manual::Delta when you upgrade!
It's worthwhile to discuss both the philosophy and actual practice of backwards compatibility in Moose, so end users know what to expect.
There are a couple principles at work.
These two principles are often related.
In this next release, methods generated by using a native trait will now check their arguments. If you try to pass an argument to an Array's count() method, it will throw an error.
We never documented this one way or another, and the current behavior is clearly wrong, so we feel that changing this is okay.
When incorrect behavior is documented, we don't remove it outright if we can possibly avoid it. Instead, we add a deprecation warning, and will remove it eventually.
This stands in contrast to other projects, like Catalyst, which has a much stronger backwards compatibility guarantee.
So that's the policy, but how about the practice?
We do a lot of testing to smoke these changes. A while back, I wrote a module called Test::DependentModules which allows you to test some or all of the modules dependent on a given module. While we don't test every dependent, since lots of them are stale, we do test quite a few. If you have something on CPAN you'd like to include in the tests, just let us know via irc or email.
When this test finds a problem with a change, we usually offer to help downstream authors change their code, and we try to synchronize new releases of Moose with new releases of dependents. It's most often MooseX modules which get broken, because many of them are intimate with the Moose internals. It's less common for modules which simply use Moose to break outright.
Fey::ORM is effectively a MooseX module, despite the name, as are a few others. Some modules, like Catalyst, poke around in the more arcane corners of Moose, and tend to be more easily broken.
We also maintain a list of conflicting module versions by hand in our Makefile.PL. Unfortunately, the CPAN toolchain doesn't (yet?) have any sort of real support for conflict handling, so all we can do is print out some warnings to the terminal at install time. I hope that in the future, there will be an official way to declare conflicts. Then CPAN clients can let the user choose how to handle them (update the conflicting module, ignore, don't install the new Moose).
Finally, we expect that end users test new versions of Moose (and of any other dependency) before deploying to production. If you don't have testing that you trust, you probably shouldn't be upgrading at all!
This is also documented in the Moose docs, but with less detail.
Hopefully this helps make our decisions a little more transparent. Comments (sans too much flame) are welcome.
]]>However, I've been doing some profiling recently of some of my Moose-using modules, and I've found some areas for improvement.
The 1.13 release addresses one of these. Previously, calls to $object->does() were fairly slow, especially for classes with a bunch of roles or deep inheritance hierarchies. The does() method ended up looking up roles in the metaclass object, and it did this in a really slow way.
With 1.13, all of a class's roles are captured in a hash, and we can look up any role in the time it takes to look up a hash key. If your app makes a lot of calls to does() then this might help. Note that calls to does can happen behind the scenes with any sort of role-based type constraint.
Next up on my list are native traits. It turns out that the code which implements these often goes through some really slow paths in Moose. I'm going to make all native traits inlined as well. In the best case, that will generate code like push @{ $self->{foo} }, @_, which will be much faster than what we do now.
perl -d:NYTProf -MMarkdent::Simple::Document -e1
The Markdent module in question loads a lot of Moose-using modules, uses plenty of roles, and is generally a good Moose compilation workout.
When profiling, I found that the biggest culprit was looking up methods in a module's namespace. We were making nearly 10,000 calls to Class::MOP::Mixin::HasMethods->get_method, which is one of our most expensive operations. I was able to reduce the number of calls to under 4,000.
What's a bit sad, however, is that this only appears to save 6-10% of the compilation time in real usage. I'm not sure why that is, but I think the issue is that the perl core's compilation time may be a big factor. As I said, loading that one Markdent modules loads a lot of modules (203 individual .pm files), and the raw overhead of simply reading all those files and compiling them may be a significant chunk of the compilation time.
It's really hard to test this theory, though, since I don't really have a non-Moose version of Markdent to test as a control.
Anyway, this latest release of Moose and CMOP at least provides some speedups. Thanks to Tim Bunce for working on Devel::NYTProf. It's a fantastic tool, and it makes profiling a pleasure to do.
]]>We'll be using this blog to announce interesting Moose projects, upcoming API changes and deprecations, and maybe to write fascinating articles about Moose (enthusiasm and energy permitting).
I've just released Moose 1.09, which includes a number of changes. Notable, this release includes an API change or two, as well as a whole bunch of deprecation warnings.
For a long time, we've been saying that features are deprecated in the Changes file, but not actually changing the code. With Moose 1.09, every feature that's been marked deprecated in the past couple years now issues a warning. To make the warnings less intrusive, I wrote a new package called Package::DeprecationManager. This module manages the deprecation warnings and ensures that a given warning only shows up once per package. This should avoid any "I upgraded and now my logs filled my disk" disasters.
Actually warning about deprecated features is the first step towards removing them in the future, so please address any warnings you see in your own code.
A number of MooseX modules will trigger these warnings. In many cases, we were able to help the CPAN authors update their code, and we added a conflict warning to the Makefile.PL, so please look out for the conflict warning. However, in the interest of getting code released, not every MooseX module has been updated. If you are using a module which now warns, please file a bug for that module. MooseX module authors, the fixes are generally very simple. If you have question, please just us in the #moose-dev IRC channel or send email to the Moose mailing list.
]]>