mop::manual::tutorials::moose_to_mop - A manual for p5-mop
This tutorial is an attempt to map some of the common Moose concepts to their MOP equivalents.
In Moose, a class is just a package which contains a use Moose declaration. After that, you use the Moose keywords: extends introduces inheritance, with adds roles, and has creates attributes in the class. After this, any subroutines created in the package are automatically added as methods of the class.
use Moose
extends
with
has
In the MOP there are explicit class, method, and attribute declarations. Here is a simple example:
class Foo extends Bar with Baz, Gorch { has $!foo; has $!bar; method foo { ... } method set_bar ($b) { ... } }
This creates a class named Foo which is a subclass of the Bar class and consumes the Baz and Gorch roles. It contains two attributes, $!foo and $!bar, and two methods, foo and set_bar. set_bar takes one argument, $b.
Foo
Bar
Baz
Gorch
$!foo
$!bar
foo
set_bar
$b
The specific details of attributes and methods will be discussed later, but the above example should provide a basic overview of the base syntax.
Classes which do not explicitly extend a superclass will automatically extend the mop::object class. This class will provide a new method which can be used to construct instances.
mop::object
new
The new method inherited from mop::object accepts a set of key/value pairs where the key is the name of an attribute (minus the sigil). The instances created by the MOP are opaque, meaning they are not HASH refs, and access to the individual slots is only possible either inside a method (where they are accessible as normal variables) or via the MOP (the details of which are left as an exercise to the reader).
If you wish to override the default constructor's behavior with regard to arguments, then you simply create a new method yourself to accept different parameters, then munge those parameters into key/value pairs before calling the mop::object constructor with next::method.
next::method
This is very similar to overriding the BUILDARGS method in a Moose class. Here is a short example:
BUILDARGS
class Foo { has $!bar; method new ($class: $b) { $class->next::method( bar => $b ); } }
It should be noted that any attempt to assign to an attribute will result in an error. So if you either need access to $self or attributes, you can do this inside of the BUILD method, which will be automatically called from new.
$self
BUILD
As with Moose, if you need to perform initialization on an instance, you can use the BUILD method for that.
Here is a simple example where the bar argument to the constructor is not actually stored, but instead is processed first, then stored in the $!double_bar attribute.
bar
$!double_bar
class Foo { has $!double_bar; method BUILD ($args) { $!double_bar = $args->{'bar'} * 2 if exists $args->{'bar'}; } }
Below is the list of options for the Moose has keyword. With each of them we will show an example of how to accomplish the same with the MOP.
This is supported by the core ro and rw traits, which are applied with the is modifier. Here is a simple example:
ro
rw
is
class Foo { has $!bar is ro; has $!baz is rw; }
There is currently no support for types in the MOP. It is possible, however, to create a type trait that can perform the same validation, and even use Moose type constraints. See t/400-traits/003-type-trait.t for an example.
type
As was said with the isa option, there is no support for types in the MOP. However it would be possible to extend the type trait in t/400-traits/003-type-trait.t to also do coercion. It might look like this:
isa
class Foo { has $!bar is type( isa => 'SomeType', coerce => 1 ); }
Actual implementation of this is left as an exercise for the reader.
This option is really just a shortcut for a type assignment so the suggestions in the above two options apply here as well.
Required attributes are easily mimicked through the MOP without even needing a trait. Here is how they are accomplished:
class Foo { has $!bar = die '$!bar is required'; }
When an instance of Foo is created and no value is supplied for $!bar, then the default will be executed, which in this case will simply die with the error message.
Weak references are accomplished using the weak_ref trait that is core in the MOP. Here is a simple example:
weak_ref
class Tree { has $!parent is weak_ref; }
Lazy attributes are supported via the core lazy trait. Here is a simple example of that:
lazy
class Foo { has $!bar is lazy; }
Unlike Moose, where lazy attributes are only re-created if the slot has not been populated, in MOP they will be populated both if the slot has not been populated and if the value in the slot is undef. This is more in line with how regular scalars work, meaning that if you define a scalar with my $foo; then it is implicitly undef and not some special "not assigned to" value.
my $foo;
There is no specific way to do trigger yet, but take a look at t/400-traits/020-moose-traits.t for a naive (and mostly wrong) version.
trigger
There is no specific way to do handles yet, but take a look at t/400-traits/020-moose-traits.t for a simple version that supports the basic HASH syntax.
handles
NOTE: This will very likely be put into the core traits, but for now it is not.
This is not currently supported, and honestly, probably never will be, since it is highly Moose specific.
There is no special trait for builder. Instead, you simply use the existing syntax for assigning default values to attributes and just call a method. Here is an example:
builder
class Foo { has $!bar = $_->build_bar; method build_bar { ... } }
The standard perl topic variable ($_) is localized to be the current instance when running the builders, so you can use it to access the current invocant.
$_
There is also no special trait for default. Instead you use the existing syntax. Here is how you would provide a simple default value:
default
class Foo { has $!bar = 10; has $!baz = {}; }
Pretty much anything you can stick in a scalar variable can go on the right hand side of a has expression.
If you need to initialize a more complex value, but for some reason do not want to use the builder style approach, you can wrap your default value in a do block, like so:
do
class Foo { has $!bar = do { $_->bar_has_been_touched; 100; }; }
While this works, most often it is better to use the builder approach.
There is no special trait for clearer. Instead it is recommended that you write a simple method that follows this pattern instead.
clearer
class Foo { has $!bar; method clear_bar { undef $!bar } }
If $!bar was lazy, this would force a recalculation of $!bar the next time that $!bar was accessed.
There is no special trait for predicate. Instead it is recommended that you write a simple method that follows this pattern instead.
predicate
class Foo { has $!bar; method has_bar { defined $!bar } }
It should be noted that if $!bar was lazy, this would force evaluation of $!bar. If you want to test if a lazy value is yet to be initialized, you need to go through the MOP to get that. Here is what that code would look like.
mop::meta($self)->get_attribute('$!bar')->has_data_in_slot_for($self)
The real lesson here is that if you want lazy and predicates, you should implement the accessors yourself. See t/001-examples/003-binary-tree.t for an example of that.
This is not currently supported in the MOP and likely won't be. To the best of my knowledge it was hardly ever actually used in Moose.
Since this module is still under development we would prefer to not use the RT bug queue and instead use the built in issue tracker on Github.
Stevan Little <stevan.little@iinteractive.com>
Jesse Luehrs <doy@tozt.net>
This software is copyright (c) 2013-2014 by Infinity Interactive.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
To install mop, copy and paste the appropriate command in to your terminal.
cpanm
cpanm mop
CPAN shell
perl -MCPAN -e shell install mop
For more information on module installation, please visit the detailed CPAN module installation guide.