This is a role which provides an alternate constructor for creating objects
using parameters passed in from the command line.

This module attempts to DWIM as much as possible with the command line
params by introspecting your class's attributes. It will use the name of
your attribute as the command line option, and if there is a type
constraint defined, it will configure Getopt::Long to handle the option
accordingly.

You can use the trait the MooseX::Getopt::Meta::Attribute::Trait manpage or
the attribute metaclass the MooseX::Getopt::Meta::Attribute manpage to get
non-default commandline option names and aliases.

You can use the trait the MooseX::Getopt::Meta::Attribute::Trait::NoGetopt
manpage or the attribute metaclass the
MooseX::Getopt::Meta::Attribute::NoGetopt manpage to have 'MooseX::Getopt'
ignore your attribute in the commandline options.

By default, attributes which start with an underscore are not given
commandline argument support, unless the attribute's metaclass is set to
the MooseX::Getopt::Meta::Attribute manpage. If you don't want your
accessors to have the leading underscore in their name, you can do this:

# for read/write attributes
has '_foo' => (accessor => 'foo', ...);

# or for read-only attributes
has '_bar' => (reader => 'bar', ...);

This will mean that Getopt will not handle a --foo param, but your code can
still call the 'foo' method.

If your class also uses a configfile-loading role based on the
MooseX::ConfigFromFile manpage, such as the MooseX::SimpleConfig manpage,
the MooseX::Getopt manpage's 'new_with_options' will load the configfile
specified by the '--configfile' option (or the default you've given for the
configfile attribute) for you.

Options specified in multiple places follow the following precendence
order: commandline overrides configfile, which overrides explicit
new_with_options parameters.

This module fills a gap in Moose by adding method parameter validation to
Moose. This is just one of many developing options, it should not be
considered the "official" one by any means though.

Authors:
--------
Stevan Little
Dave Rolsky

The types provided with Moose are by design global. This package helps you
to organise and selectively import your own and the built-in types in
libraries. As a nice side effect, it catches typos at compile-time too.
However, the main reason for this module is to provide an easy way to not
have conflicts with your type names, since the internal fully qualified
names of the types will be prefixed with the library's name.
This module will also provide you with some helper functions to make it
easier to use Moose types in your code.

A set of commonly-used type constraints that do not ship with Moose by
default.

A MooseX::Types library for creating parameterizable types. A
parameterizable type constraint for all intents and uses is a subclass of
a parent type, but adds additional type parameters which are available to
constraint callbacks (such as inside the 'where' clause of a type
constraint definition) or in the coercions you define for a given type
constraint.

Keeping packages clean
When you define a function, or import one, into a Perl package, it will
naturally also be available as a method. This does not per se cause
problems, but it can complicate subclassing and, for example, plugin
classes that are included via multiple inheritance by loading them as
base classes.

The 'namespace::clean' pragma will remove all previously declared or
imported symbols at the end of the current package's compile cycle.
Functions called in the package itself will still be bound by their
name, but they won't show up as methods on your class or instances.

'Net::CIDR::Set' represents sets of IP addresses and allows standard set
operations (union, intersection, membership test etc) to be performed on
them.

In spite of the name it can work with sets consisting of arbitrary ranges
of IP addresses - not just CIDR blocks.

Both IPv4 and IPv6 addresses are handled - but they may not be mixed in the
same set. You may explicitly set the personality of a set:

my $ip4set = Net::CIDR::Set->new({ type => 'ipv4 }, '10.0.0.0/8');

Normally this isn't necessary - the set will guess its personality from the
first data that is added to it.

Net::DNS is a Perl interface to the DNS resolver. It allows the
programmer to perform any type of DNS query from a Perl script. For
details and examples, please read the Net::DNS manual page.

The 'Net::HTTP' class is a low-level HTTP client. An instance of the
'Net::HTTP' class represents a connection to an HTTP server. The HTTP
protocol is described in RFC 2616. The 'Net::HTTP' class supports
'HTTP/1.0' and 'HTTP/1.1'.

'Net::HTTP' is a sub-class of 'IO::Socket::INET'. You can mix the methods
described below with reading and writing from the socket directly. This is
not necessary a good idea, unless you know what you are doing.

You can either use the simple interface, which does one ident lookup at a
time, or use the asynchronous interface to perform (possibly) many
simultaneous lookups, or simply continue serving other things while the
lookup is proceeding.

This is the Net::IP module, designed to allow easy manipulation of IPv4
and IPv6 addresses.

Net::Jabber is a convenient tool to use for any perl script that would
like to utilize the Jabber Instant Messaging protocol. While not a
client in and of itself, it provides all of the necessary back-end
functions to make a CGI client or command-line perl client feasible and
easy to use. Net::Jabber is a wrapper around the rest of the official
Net::Jabber::xxxxxx packages.

Parse, manipulate and lookup IP network blocks.

Net::Server is an extensible, generic Perl server engine. Net::Server
combines the good properties from Net::Daemon (0.34), NetServer::Generic
(1.03), and Net::FTPServer (1.0), and also from various concepts in the
Apache Webserver.

Implements the same API as Net::SMTP, but uses IO::Socket::SSL for its
network operations. Due to the nature of 'Net::SMTP''s 'new' method, it is
not overridden to make use of a default port for the SMTPS service. Perhaps
future versions will be smart like that. Port '465' is usually what you
want, and it's not a pain to specify that.

For interface documentation, please see Net::SMTP.

The Net::SNMP module abstracts the intricate details of the Simple
Network Management Protocol by providing a high level programming
interface to the protocol. Each Net::SNMP object provides a one-to-one
mapping between a Perl object and a remote SNMP agent or manager. Once an
object is created, it can be used to perform the basic protocol exchange
actions defined by SNMP.

There is a related module called Net::SSLeay::Handle included in this
distribution that you might want to use instead. It has its own pod
documentation.

Net::Telnet allows you to make client connections to a TCP port and do
network I/O, especially to a port using the TELNET protocol. Simple
I/O methods such as print, get, and getline are provided. More
sophisticated interactive features are provided because connecting to a
TELNET port ultimately means communicating with a program designed for
human interaction. These interactive features include the ability to
specify a time-out and to wait for patterns to appear in the input
stream, such as the prompt from a shell.

Net::XMPP is a convenient tool to use for any perl script that would
like to utilize the XMPP Instant Messaging protocol. While not a
client in and of itself, it provides all of the necessary back-end
functions to make a CGI client or command-line perl client feasible and
easy to use. Net::XMPP is a wrapper around the rest of the official
Net::XMPP::xxxxxx packages.

This module provides an interface to the protocol family represented by
IMAP, IMSP, ACAP, and ICAP. A usable IMAP module is also provide.

OLE::Storage_Lite allows you to read and write an OLE structured file.

OLE::Storage_Lite::PPS is a class representing PPS.
OLE::Storage_Lite::PPS::Root, OLE::Storage_Lite::PPS::File and
OLE::Storage_Lite::PPS::Dir are subclasses of OLE::Storage_Lite::PPS.

This module lets you quickly and easily construct new packages.
It gives them unused names and sets up their package data,
if provided.

Author: Ricardo Signes,

This module provides various type-testing functions. These are intended for
functions that, unlike most Perl code, care what type of data they are
operating on. For example, some functions wish to behave differently
depending on the type of their arguments (like overloaded functions in
C++).

There are two flavours of function in this module. Functions of the first
flavour only provide type classification, to allow code to discriminate
between argument types. Functions of the second flavour package up the most
common type of type discrimination: checking that an argument is of an
expected type. The functions come in matched pairs, of the two flavours,
and so the type enforcement functions handle only the simplest requirements
for arguments of the types handled by the classification functions.
Enforcement of more complex types may, of course, be built using the
classification functions, or it may be more convenient to use a module
designed for the more complex job, such as the Params::Validate manpage.

This module is implemented in XS, with a pure Perl backup version for
systems that can't handle XS.