Ports Search

It is stupidly complicated to detect whether a given scalar is a filehandle (or something filehandle like) in Perl. This module attempts to do so, but probably falls short in some cases. The primary advantage of using this module is that it gives you somebody to blame (me) if your code can't detect a filehandle. The main use case for IO::Detect is for when you are writing functions and you want to allow the caller to pass a file as an argument without being fussy as to whether they pass a file name or a file handle.

Perl module for static variables without namespace pollution Lexical::Var and Lexical::Sub implement lexical scoping of static variables and subroutines. Although it can be used directly, it is mainly intended to be infrastructure for modules that export particular objects. Lexical::Var only manages variables of static duration (the kind of duration that our and state variables have). To get a fresh variable for each invocation of a function, use my. Lexical::Sub is implemented through the mechanism of Lexical::Var. Its distinct name and declaration syntax exist to make lexical subroutine declarations clearer.

Log::Dispatch::ArrayWithLimits functions similarly to Log::Dispatch::Array, with a few differences: - only the messages (strings) are stored - allow specifying array variable name (e.g. "My::array" instead of \@My:array) This makes it possible to use in Log::Log4perl configuration, which is a text file. - can apply some limits Currently only max_elems (the maximum number of elements in the array) is available. Future limits will be added (see "TODO"). Logging to an in-process array can be useful when debugging/testing, or when you want to let users of your program connect to your program to request viewing the ogs being produced.

Log::Dispatch::Config is a wrapper for Log::Dispatch and provides a way to configure Log::Dispatch objects with configuration files. Somewhat like a lite version of log4j and Log::Log4perl it allows multiple log destinations. The standard configuration file format for Log::Dispatch::Config is AppConfig. This module plugs in to Log::Dispatch::Config and allows the use of other file formats, in fact any format supported by the Config::Any module. As a bonus you can also pass in a configuration data structure instead of a file name.

Moo is an extremely light-weight Object Orientation system. It allows one to concisely define objects and roles with a convenient syntax that avoids the details of Perl's object system. Moo contains a subset of Moose and is optimised for rapid startup. The name Moo is based on the idea that it provides almost -- but not quite -- two thirds of Moose. Unlike Mouse this module does not aim at full compatibility with Moose's surface syntax, preferring instead to provide full interoperability via metaclass inflation capabilities.

This module creates and manipulates PAR distributions. They are architecture-specific PAR files, containing everything under blib/ of CPAN distributions after their "make" or "Build" stage, a META.yml describing metadata of the original CPAN distribution, and a MANIFEST detailing all files within it. Digitally signed PAR distributions will also contain a SIGNATURE file. The naming convention for such distributions is: $NAME-$VERSION-$ARCH-$PERL_VERSION.par For example, "PAR-Dist-0.01-i386-freebsd-5.8.0.par" corresponds to the 0.01 release of "PAR-Dist" on CPAN, built for perl 5.8.0 running on "i386-freebsd".

A structured type constraint is a standard container Moose type constraint, such as an ArrayRef or HashRef, which has been enhanced to allow you to explicitly name all the allowed type constraints inside the structure. The generalized form is: TypeConstraint[@TypeParameters or %TypeParameters] Where 'TypeParameters' is an array reference or hash references of Moose::Meta::TypeConstraint objects. This type library enables structured type constraints. It is built on top of the MooseX::Types library system, so you should review the documentation for that if you are not familiar with it.

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.

When you import a function into a Perl package, it will naturally also be available as a method. The namespace::autoclean pragma will remove all 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. This module is very similar to namespace::clean, except it will clean all imported functions, no matter if you imported them before or after you used the pragma. It will also not touch anything that looks like a method, according to Class::MOP::Class::get_method_list.

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.