Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Moose(3)	      User Contributed Perl Documentation	      Moose(3)

       Moose - A postmodern object system for Perl 5

       version 2.2013

	 package Point;
	 use Moose; # automatically turns on strict and	warnings

	 has 'x' => (is	=> 'rw', isa =>	'Int');
	 has 'y' => (is	=> 'rw', isa =>	'Int');

	 sub clear {
	     my	$self =	shift;

	 package Point3D;
	 use Moose;

	 extends 'Point';

	 has 'z' => (is	=> 'rw', isa =>	'Int');

	 after 'clear' => sub {
	     my	$self =	shift;

       Moose is	an extension of	the Perl 5 object system.

       The main	goal of	Moose is to make Perl 5	Object Oriented	programming
       easier, more consistent,	and less tedious. With Moose you can think
       more about what you want	to do and less about the mechanics of OOP.

       Additionally, Moose is built on top of Class::MOP, which	is a metaclass
       system for Perl 5. This means that Moose	not only makes building	normal
       Perl 5 objects better, but it provides the power	of metaclass
       programming as well.

   New to Moose?
       If you're new to	Moose, the best	place to start is the Moose::Manual
       docs, followed by the Moose::Cookbook. The intro	will show you what
       Moose is, and how it makes Perl 5 OO better.

       The cookbook recipes on Moose basics will get you up to speed with many
       of Moose's features quickly. Once you have an idea of what Moose	can
       do, you can use the API documentation to	get more detail	on features
       which interest you.

   Moose Extensions
       The "MooseX::" namespace	is the official	place to find Moose
       extensions.  These extensions can be found on the CPAN.	The easiest
       way to find them	is to search for them
       (<>), or to examine Task::Moose
       which aims to keep an up-to-date, easily	installable list of Moose

       Much of the Moose documentation has been	translated into	other

	   Japanese docs can be	found at
	   The source POD files	can be found in	GitHub:

       Moose makes every attempt to provide as much convenience	as possible
       during class construction/definition, but still stay out	of your	way if
       you want	it to. Here are	a few items to note when building classes with

       When you	"use Moose", Moose will	set the	class's	parent class to
       Moose::Object, unless the class using Moose already has a parent	class.
       In addition, specifying a parent	with "extends" will change the parent

       Moose will also manage all attributes (including	inherited ones)	that
       are defined with	"has". And (assuming you call "new", which is
       inherited from Moose::Object) this includes properly initializing all
       instance	slots, setting defaults	where appropriate, and performing any
       type constraint checking	or coercion.

       Moose provides a	number of methods to all your classes, mostly through
       the inheritance of Moose::Object. There is however, one exception. By
       default,	Moose will install a method named "meta" in any	class which
       uses "Moose". This method returns the current class's metaclass.

       If you'd	like to	rename this method, you	can do so by passing the
       "-meta_name" option when	using Moose:

	   use Moose -meta_name	=> 'my_meta';

       However,	the Moose::Object class	also provides a	method named "meta"
       which does the same thing. If your class	inherits from Moose::Object
       (which is the default), then you	will still have	a "meta" method.
       However,	if your	class inherits from a parent which provides a "meta"
       method of its own, your class will inherit that instead.

       If you'd	like for Moose to not install a	meta method at all, you	can
       pass "undef" as the "-meta_name"	option:

	   use Moose -meta_name	=> undef;

       Again, you will still inherit "meta" from Moose::Object in this case.

       Moose will export a number of functions into the	class's	namespace
       which may then be used to set up	the class. These functions all work
       directly	on the current class.

   extends (@superclasses)
       This function will set the superclass(es) for the current class.	If the
       parent classes are not yet loaded, then "extends" tries to load them.

       This approach is	recommended instead of "use base"/"use parent",
       because "use base" actually "push"es onto the class's @ISA, whereas
       "extends" will replace it. This is important to ensure that classes
       which do	not have superclasses still properly inherit from

       Each superclass can be followed by a hash reference with	options.
       Currently, only -version	is recognized:

	   extends 'My::Parent'	     =>	{ -version => 0.01 },
		   'My::OtherParent' =>	{ -version => 0.03 };

       An exception will be thrown if the version requirements are not

   with	(@roles)
       This will apply a given set of @roles to	the local class.

       Like with "extends", each specified role	can be followed	by a hash
       reference with a	-version option:

	   with	'My::Role'	=> { -version => 0.32 },
		'My::Otherrole'	=> { -version => 0.23 };

       The specified version requirements must be satisfied, otherwise an
       exception will be thrown.

       If your role takes options or arguments,	they can be passed along in
       the hash	reference as well.

       You should only use one "with", even if you are consuming multiple
       roles. If you consume roles using multiple "with" statements Moose
       cannot detect method conflicts between those roles.

   has $name|@$names =>	%options
       This will install an attribute of a given $name into the	current	class.
       If the first parameter is an array reference, it	will create an
       attribute for every $name in the	list. The %options will	be passed to
       the constructor for Moose::Meta::Attribute (which inherits from
       Class::MOP::Attribute), so the full documentation for the valid options
       can be found there. These are the most commonly used options:

       is =_ 'rw'|'ro'
	   The is option accepts either	rw (for	read/write) or ro (for read
	   only). These	will create either a read/write	accessor or a read-
	   only	accessor respectively, using the same name as the $name	of the

	   If you need more control over how your accessors are	named, you can
	   use the reader, writer and accessor options inherited from
	   Class::MOP::Attribute, however if you use those, you	won't need the
	   is option.

       isa =_ $type_name
	   The isa option uses Moose's type constraint facilities to set up
	   runtime type	checking for this attribute. Moose will	perform	the
	   checks during class construction, and within	any accessors. The
	   $type_name argument must be a string. The string may	be either a
	   class name or a type	defined	using Moose's type definition
	   features. (Refer to Moose::Util::TypeConstraints for	information on
	   how to define a new type, and how to	retrieve type meta-data).

       coerce =_ (1|0)
	   This	will attempt to	use coercion with the supplied type constraint
	   to change the value passed into any accessors or constructors. You
	   must	supply a type constraint, and that type	constraint must	define
	   a coercion. See Moose::Cookbook::Basics::HTTP_SubtypesAndCoercion
	   for an example.

       does =_ $role_name
	   This	will accept the	name of	a role which the value stored in this
	   attribute is	expected to have consumed.

       required	=_ (1|0)
	   This	marks the attribute as being required. This means a value must
	   be supplied during class construction, or the attribute must	be
	   lazy	and have either	a default or a builder.	Note that "required"
	   does	not say	anything about the attribute's value, which can	be

       weak_ref	=_ (1|0)
	   This	will tell the class to store the value of this attribute as a
	   weakened reference. If an attribute is a weakened reference,	it
	   cannot also be coerced. Note	that when a weak ref expires, the
	   attribute's value becomes undefined,	and is still considered	to be
	   set for purposes of predicate, default, etc.

       lazy =_ (1|0)
	   This	will tell the class to not create this slot until absolutely
	   necessary.  If an attribute is marked as lazy it must have a
	   default or builder supplied.

       trigger =_ $code
	   The trigger option is a CODE	reference which	will be	called after
	   the value of	the attribute is set. The CODE ref is passed the
	   instance itself, the	updated	value, and the original	value if the
	   attribute was already set.

	   You can have	a trigger on a read-only attribute.

	   NOTE: Triggers will only fire when you assign to the	attribute,
	   either in the constructor, or using the writer. Default and built
	   values will not cause the trigger to	be fired.

	   The handles option provides Moose classes with automated delegation
	   features.  This is a	pretty complex and powerful option. It accepts
	   many	different option formats, each with its	own benefits and

	   NOTE: The class being delegated to does not need to be a Moose
	   based class,	which is why this feature is especially	useful when
	   wrapping non-Moose classes.

	   All handles option formats share the	following traits:

	   You cannot override a locally defined method	with a delegated
	   method; an exception	will be	thrown if you try. That	is to say, if
	   you define "foo" in your class, you cannot override it with a
	   delegated "foo". This is almost never something you would want to
	   do, and if it is, you should	do it by hand and not use Moose.

	   You cannot override any of the methods found	in Moose::Object, or
	   the "BUILD" and "DEMOLISH" methods. These will not throw an
	   exception, but will silently	move on	to the next method in the
	   list. My reasoning for this is that you would almost	never want to
	   do this, since it usually breaks your class.	As with	overriding
	   locally defined methods, if you do want to do this, you should do
	   it manually,	not with Moose.

	   You do not need to have a reader (or	accessor) for the attribute in
	   order to delegate to	it. Moose will create a	means of accessing the
	   value for you, however this will be several times less efficient
	   then	if you had given the attribute a reader	(or accessor) to use.

	   Below is the	documentation for each option format:

	       This is the most	common usage for handles. You basically	pass a
	       list of method names to be delegated, and Moose will install a
	       delegation method for each one.

	       This is the second most common usage for	handles. Instead of a
	       list of method names, you pass a	HASH ref where each key	is the
	       method name you want installed locally, and its value is	the
	       name of the original method in the class	being delegated	to.

	       This can	be very	useful for recursive classes like trees. Here
	       is a quick example (soon	to be expanded into a Moose::Cookbook

		 package Tree;
		 use Moose;

		 has 'node' => (is => 'rw', isa	=> 'Any');

		 has 'children'	=> (
		     is	     =>	'ro',
		     isa     =>	'ArrayRef',
		     default =>	sub { [] }

		 has 'parent' => (
		     is		 => 'rw',
		     isa	 => 'Tree',
		     weak_ref	 => 1,
		     handles	 => {
			 parent_node =>	'node',
			 siblings    =>	'children',

	       In this example,	the Tree package gets "parent_node" and
	       "siblings" methods, which delegate to the "node"	and "children"
	       methods (respectively) of the Tree instance stored in the
	       "parent"	slot.

	       You may also use	an array reference to curry arguments to the
	       original	method.

		 has 'thing' =>	(
		     handles =>	{ set_foo => [ set => 'foo' ] },

		 # $self->set_foo(...) calls $self->thing->set('foo', ...)

	       The first element of the	array reference	is the original	method
	       name, and the rest is a list of curried arguments.

	       The regexp option works very similar to the ARRAY option,
	       except that it builds the list of methods for you. It starts by
	       collecting all possible methods of the class being delegated
	       to, then	filters	that list using	the regexp supplied here.

	       NOTE: An	isa option is required when using the regexp option
	       format. This is so that we can determine	(at compile time) the
	       method list from	the class.  Without an isa this	is just	not

	   "ROLE" or "ROLETYPE"
	       With the	role option, you specify the name of a role or a role
	       type whose "interface" then becomes the list of methods to
	       handle. The "interface" can be defined as; the methods of the
	       role and	any required methods of	the role. It should be noted
	       that this does not include any method modifiers or generated
	       attribute methods (which	is consistent with role	composition).

	       With the	duck type option, you pass a duck type object whose
	       "interface" then	becomes	the list of methods to handle. The
	       "interface" can be defined as the list of methods passed	to
	       "duck_type" to create a duck type object. For more information
	       on "duck_type" please check Moose::Util::TypeConstraints.

	       This is the option to use when you really want to do something
	       funky. You should only use it if	you really know	what you are
	       doing, as it involves manual metaclass twiddling.

	       This takes a code reference, which should expect	two arguments.
	       The first is the	attribute meta-object this handles is attached
	       to. The second is the metaclass of the class being delegated
	       to. It expects you to return a hash (not	a HASH ref) of the
	       methods you want	mapped.

       traits =_ [ @role_names ]
	   This	tells Moose to take the	list of	@role_names and	apply them to
	   the attribute meta-object. Custom attribute metaclass traits	are
	   useful for extending	the capabilities of the	has keyword: they are
	   the simplest	way to extend the MOP, but they	are still a fairly
	   advanced topic and too much to cover	here.

	   See "Metaclass and Trait Name Resolution" for details on how	a
	   trait name is resolved to a role name.

	   Also	see Moose::Cookbook::Meta::Labeled_AttributeTrait for a
	   metaclass trait example.

       builder => Str
	   The value of	this key is the	name of	the method that	will be	called
	   to obtain the value used to initialize the attribute. See the
	   builder option docs in Class::MOP::Attribute	and/or
	   Moose::Cookbook::Basics::BinaryTree_BuilderAndLazyBuild for more

       default => SCALAR | CODE
	   The value of	this key is the	default	value which will initialize
	   the attribute.

	   NOTE: If the	value is a simple scalar (string or number), then it
	   can be just passed as is.  However, if you wish to initialize it
	   with	a HASH or ARRAY	ref, then you need to wrap that	inside a CODE
	   reference.  See the default option docs in Class::MOP::Attribute
	   for more information.

       clearer => Str
	   Creates a method allowing you to clear the value. See the clearer
	   option docs in Class::MOP::Attribute	for more information.

       predicate => Str
	   Creates a method to perform a basic test to see if a	value has been
	   set in the attribute. See the predicate option docs in
	   Class::MOP::Attribute for more information.

	   Note	that the predicate will	return true even for a "weak_ref"
	   attribute whose value has expired.

       documentation =>	$string
	   An arbitrary	string that can	be retrieved later by calling

   has +$name => %options
       This is variation on the	normal attribute creator "has" which allows
       you to clone and	extend an attribute from a superclass or from a	role.
       Here is an example of the superclass usage:

	 package Foo;
	 use Moose;

	 has 'message' => (
	     is	     =>	'rw',
	     isa     =>	'Str',
	     default =>	'Hello,	I am a Foo'

	 package My::Foo;
	 use Moose;

	 extends 'Foo';

	 has '+message'	=> (default => 'Hello I	am My::Foo');

       What is happening here is that My::Foo is cloning the "message"
       attribute from its parent class Foo, retaining the "is => 'rw'" and
       "isa => 'Str'" characteristics, but changing the	value in "default".

       Here is another example,	but within the context of a role:

	 package Foo::Role;
	 use Moose::Role;

	 has 'message' => (
	     is	     =>	'rw',
	     isa     =>	'Str',
	     default =>	'Hello,	I am a Foo'

	 package My::Foo;
	 use Moose;

	 with 'Foo::Role';

	 has '+message'	=> (default => 'Hello I	am My::Foo');

       In this case, we	are basically taking the attribute which the role
       supplied	and altering it	within the bounds of this feature.

       Note that you can only extend an	attribute from either a	superclass or
       a role, you cannot extend an attribute in a role	that composes over an
       attribute from another role.

       Aside from where	the attributes come from (one from superclass, the
       other from a role), this	feature	works exactly the same.	This feature
       is restricted somewhat, so as to	try and	force at least some sanity
       into it.	Most options work the same, but	there are some exceptions:

	   These options can be	added, but cannot override a superclass

	   You are allowed to add additional traits to the "traits"
	   definition.	These traits will be composed into the attribute, but
	   preexisting traits are not overridden, or removed.

   before $name|@names|\@names|qr/.../ => sub {	... }
   after $name|@names|\@names|qr/.../ => sub { ... }
   around $name|@names|\@names|qr/.../ => sub {	... }
       These three items are syntactic sugar for the before, after, and	around
       method modifier features	that Class::MOP	provides. More information on
       these may be found in Moose::Manual::MethodModifiers and	the
       Class::MOP::Class documentation.

   override ($name, &sub)
       An "override" method is a way of	explicitly saying "I am	overriding
       this method from	my superclass".	You can	call "super" within this
       method, and it will work	as expected. The same thing can	be
       accomplished with a normal method call and the "SUPER::"	pseudo-
       package;	it is really your choice.

       The keyword "super" is a	no-op when called outside of an	"override"
       method. In the context of an "override" method, it will call the	next
       most appropriate	superclass method with the same	arguments as the
       original	method.

   augment ($name, &sub)
       An "augment" method, is a way of	explicitly saying "I am	augmenting
       this method from	my superclass".	Once again, the	details	of how "inner"
       and "augment" work is best described in the

       The keyword "inner", much like "super", is a no-op outside of the
       context of an "augment" method. You can think of	"inner"	as being the
       inverse of "super"; the details of how "inner" and "augment" work is
       best described in the

       This is the "Scalar::Util::blessed" function. It	is highly recommended
       that this is used instead of "ref" anywhere you need to test for	an
       object's	class name.

       This is the "Carp::confess" function, and exported here for historical

       When you	use Moose, you can specify traits which	will be	applied	to
       your metaclass:

	   use Moose -traits =>	'My::Trait';

       This is very similar to the attribute traits feature. When you do this,
       your class's "meta" object will have the	specified traits applied to

   Metaclass and Trait Name Resolution
       By default, when	given a	trait name, Moose simply tries to load a class
       of the same name. If such a class does not exist, it then looks for a
       class matching Moose::Meta::$type::Custom::Trait::$trait_name. The
       $type variable here will	be one of Attribute or Class, depending	on
       what the	trait is being applied to.

       If a class with this long name exists, Moose checks to see if it	has
       the method "register_implementation". This method is expected to	return
       the real	class name of the trait. If there is no
       "register_implementation" method, it will fall back to using
       Moose::Meta::$type::Custom::Trait::$trait as the	trait name.

       The lookup method for metaclasses is the	same, except that it looks for
       a class matching	Moose::Meta::$type::Custom::$metaclass_name.

       If all this is confusing, take a	look at
       Moose::Cookbook::Meta::Labeled_AttributeTrait, which demonstrates how
       to create an attribute trait.

       Moose offers a way to remove the	keywords it exports, through the
       "unimport" method. You simply have to say "no Moose" at the bottom of
       your code for this to work. Here	is an example:

	   package Person;
	   use Moose;

	   has 'first_name' => (is => 'rw', isa	=> 'Str');
	   has 'last_name'  => (is => 'rw', isa	=> 'Str');

	   sub full_name {
	       my $self	= shift;
	       $self->first_name . ' ' . $self->last_name

	   no Moose; # keywords	are removed from the Person package

       To learn	more about extending Moose, we recommend checking out the
       "Extending" recipes in the Moose::Cookbook, starting with
       Moose::Cookbook::Extending::ExtensionOverview, which provides an
       overview	of all the different ways you might extend Moose.
       Moose::Exporter and Moose::Util::MetaRole are the modules which provide
       the majority of the extension functionality, so reading their
       documentation should also be helpful.

   The MooseX::	namespace
       Generally if you're writing an extension	for Moose itself you'll	want
       to put your extension in	the "MooseX::" namespace. This namespace is
       specifically for	extensions that	make Moose better or different in some
       fundamental way.	It is traditionally not	for a package that just
       happens to use Moose. This namespace follows from the examples of the
       "LWPx::"	and "DBIx::" namespaces	that perform the same function for
       "LWP" and "DBI" respectively.

       Metaclass compatibility is a thorny subject. You	should start by
       reading the "About Metaclass compatibility" section in the Class::MOP

       Moose will attempt to resolve a few cases of metaclass incompatibility
       when you	set the	superclasses for a class, in addition to the cases
       that Class::MOP handles.

       Moose tries to determine	if the metaclasses only	"differ	by roles".
       This means that the parent and child's metaclass	share a	common
       ancestor	in their respective hierarchies, and that the subclasses under
       the common ancestor are only different because of role applications.
       This case is actually fairly common when	you mix	and match various
       "MooseX::*" modules, many of which apply	roles to the metaclass.

       If the parent and child do differ by roles, Moose replaces the
       metaclass in the	child with a newly created metaclass. This metaclass
       is a subclass of	the parent's metaclass which does all of the roles
       that the	child's	metaclass did before being replaced. Effectively, this
       means the new metaclass does all	of the roles done by both the parent's
       and child's original metaclasses.

       Ultimately, this	is all transparent to you except in the	case of	an
       unresolvable conflict.

       It should be noted that "super" and "inner" cannot be used in the same
       method. However,	they may be combined within the	same class hierarchy;
       see t/basics/override_augment_inner_super.t for an example.

       The reason for this is that "super" is only valid within	a method with
       the "override" modifier,	and "inner" will never be valid	within an
       "override" method. In fact, "augment" will skip over any	"override"
       methods when searching for its appropriate "inner".

       This might seem like a restriction, but I am of the opinion that
       keeping these two features separate (yet	interoperable) actually	makes
       them easy to use, since their behavior is then easier to	predict. Time
       will tell whether I am right or not (UPDATE: so far so good).

       We offer	both a mailing list and	a very active IRC channel.

       The mailing list	is <>. You	must be	subscribed to
       send a message. To subscribe, send an empty message to

       You can also visit us at	"#moose" on <irc://>	This
       channel is quite	active,	and questions at all levels (on	Moose-related
       topics ;) are welcome.

       Moose doesn't stand for one thing in particular,	however, if you	want,
       here are	a few of our favorites.	Feel free to contribute	more!

       o   Make	Other Object Systems Envious

       o   Makes Object	Orientation So Easy

       o   Makes Object	Orientation Spiffy- Er (sorry ingy)

       o   Most	Other Object Systems Emasculate

       o   Moose Often Ovulate Sorta Early

       o   Moose Offers	Often Super Extensions

       o   Meta	Object Obligates Salivary Excitation

       o   Meta	Object Orientation Syntax Extensions

       o   Moo,	Only Overengineered, Slow, and Execrable (blame	rjbs!)

       o   Massive Object-Oriented Stacktrace Emitter

       I blame Sam Vilain for introducing me to	the insanity that is meta-
       I blame Audrey Tang for then encouraging	my meta-model habit in #perl6.
       Without Yuval "nothingmuch" Kogman this module would not	be possible,
       and it certainly	wouldn't have this name	;P
       The basis of the	TypeContraints module was Rob Kinyon's idea
       originally, I just ran with it.
       Thanks to mst & chansen and the whole #moose posse for all the early
       Thanks to David "Theory"	Wheeler	for meta-discussions and spelling

	   This	is the official	web home of Moose. It contains links to	our
	   public git repository, as well as links to a	number of talks	and
	   articles on Moose and Moose related technologies.

       the Moose manual
	   This	is an introduction to Moose which covers most of the basics.

       Modern Perl, by chromatic
	   This	is an introduction to modern Perl programming, which includes
	   a section on	Moose. It is available in print	and as a free download
	   from	<>.

       The Moose is flying, a tutorial by Randal Schwartz
	   Part	1 - <>

	   Part	2 - <>

       Several Moose extension modules in the "MooseX::" namespace.
	   See <>	for extensions.

       The Art of the MetaObject Protocol
	   I mention this in the Class::MOP docs too, as this book was
	   critical in the development of both modules and is highly

	   This	paper (suggested by lbr	on #moose) was what lead to the
	   implementation of the "super"/"override" and	"inner"/"augment"
	   features. If	you really want	to understand them, I suggest you read

       All complex software has	bugs lurking in	it, and	this module is no

       Please report any bugs to "", or through the web
       interface at <>. You can also submit a	"TODO" test as
       a pull request at <>.

       You can also discuss feature requests or	possible bugs on the Moose
       mailing list ( or	on IRC at <irc://>.

       We are very strict about	what features we add to	the Moose core,
       especially the user-visible features. Instead we	have made sure that
       the underlying meta-system of Moose is as extensible as possible	so
       that you	can add	your own features easily.

       That said, occasionally there is	a feature needed in the	meta-system to
       support your planned extension, in which	case you should	either email
       the mailing list	( or join us on IRC at
       <irc://> to discuss. The Moose::Manual::Contributing
       has more	detail about how and when you can contribute.

       There are only a	few people with	the rights to release a	new version of
       Moose. The Moose	Cabal are the people to	go to with questions regarding
       the wider purview of Moose. They	help maintain not just the code	but
       the community as	well. See the list below under "AUTHORS".

       Moose is	a community project, and as such, involves the work of many,
       many members of the community beyond just the members in	the cabal. In

       Dave (autarch) Rolsky wrote most	of the documentation in	Moose::Manual.

       John (jgoulah) Goulah wrote Moose::Cookbook::Snack::Keywords.

       Jess (castaway) Robinson	wrote Moose::Cookbook::Snack::Types.

       Aran (bluefeet) Clary Deltac wrote

       Anders (Debolaz)	Nor Berle contributed Test::Moose and Moose::Util.

       Also, the code in Moose::Meta::Attribute::Native	is based on code from
       the MooseX::AttributeHelpers distribution, which	had contributions

       Chris (perigrin)	Prather

       Cory (gphat) Watson

       Evan Carroll

       Florian (rafl) Ragwitz

       Jason May

       Jay Hannah

       Jesse (doy) Luehrs

       Paul (frodwith) Driver

       Robert (rlb3) Boone

       Robert Buels

       Robert (phaylon)	Sedlacek

       Shawn (Sartak) Moore

       Stevan Little

       Tom (dec) Lanyon

       Yuval Kogman

       Finally,	these people also contributed various tests, bug fixes,
       documentation, and features to the Moose	codebase:


       Adam (Alias) Kennedy

       Christian (chansen) Hansen

       Cory (gphat) Watson

       Dylan Hardison (doc fixes)

       Eric (ewilhelm) Wilhelm

       Evan Carroll

       Guillermo (groditi) Roditi

       Jason May

       Jay Hannah

       Jonathan	(jrockway) Rockway

       Matt (mst) Trout

       Nathan (kolibrie) Gray

       Paul (frodwith) Driver

       Piotr (dexter) Roszatycki

       Robert Buels

       Robert (phaylon)	Sedlacek

       Robert (rlb3) Boone

       Sam (mugwump) Vilain

       Scott (konobi) McWhirter

       Shlomi (rindolf)	Fish

       Tom (dec) Lanyon

       Wallace (wreis) Reis

       ... and many other #moose folks

       o   Stevan Little <>

       o   Dave	Rolsky <>

       o   Jesse Luehrs	<>

       o   Shawn M Moore <>

       o   xxxx	x<section>xx'xx	(Yuval Kogman) <>

       o   Karen Etheridge <>

       o   Florian Ragwitz <>

       o   Hans	Dieter Pearcey <>

       o   Chris Prather <>

       o   Matt	S Trout	<>

       This software is	copyright (c) 2006 by Infinity Interactive, Inc.

       This is free software; you can redistribute it and/or modify it under
       the same	terms as the Perl 5 programming	language system	itself.

perl v5.32.0			  2020-07-21			      Moose(3)


Want to link to this manual page? Use this URL:

home | help