Ports Search

This class facilitates building frameworks of several classes that inter-operate. It was first designed and built for "HTML::Mason", in which the Compiler, Lexer, Interpreter, Resolver, Component, Buffer, and several other objects must create each other transparently, passing the appropriate parameters to the right class, possibly substituting their own subclass for any of these objects. The main features of "Class::Container" are: * Declaration of parameters used by each member in a class framework * Transparent passing of constructor parameters to the class that needs them * Ability to create one (automatic) or many (manual) contained objects automatically and transparently

This is a simple, safe and streamlined toolkit for building inside-out objects. Unlike most other inside-out object building modules already on CPAN, this module aims for minimalism and robustness: * Does not require derived classes to subclass it * Uses no source filters, attributes or CHECK blocks * Supports any underlying object type including foreign inheritance * Does not leak memory on object destruction * Overloading-safe * Thread-safe for Perl 5.8 or better * mod_perl compatible * Makes no assumption about inheritance or initializer needs It provides the minimal support necessary for creating safe inside-out objects and generating flexible accessors.

Most programmers who use Perl's object-oriented features construct their objects by blessing a hash. But, in doing so, they undermine the robustness of the OO approach. Hash-based objects are unencapsulated: their entries are open for the world to access and modify. Objects without effective encapsulation are vulnerable. Instead of politely respecting their public interface, some clever client coder inevitably will realize that it's marginally faster to interact directly with the underlying implementation, pulling out attribute values directly from the hash of an object.

Config::Tiny is a perl class to read and write .ini style configuration files with as little code as possible, reducing load time and memory overhead. Memory usage is normally scoffed at in Perl, but in my opinion should be at least kept in mind. This module is primarily for reading human written files, and anything we write shouldn't need to have documentation/comments. If you need something with more power, move up to Config::Simple, Config::General or one of the many other Config:: modules.

This module was written because I stumbled on some serious issues of Readonly that aren't easily fixable without breaking backwards compatibility in subtle ways. In particular Readonly's use of ties is a source of subtle bugs and bad performance. Instead, this module uses the builtin readonly feature of perl, making access to the variables just as fast as any normal variable without the weird side-effects of ties. Readonly can do the same for scalars when Readonly::XS is installed, but chooses not to do so in the most common case.

File::Find::Object does same job as File::Find but works like an object and with an iterator. As File::Find is not object oriented, one cannot perform multiple searches in the same application. The second problem of File::Find is its file processing: after starting its main loop, one cannot easily wait for another event an so get the next result. With File::Find::Object you can get the next file by calling the next() function, but setting a callback is still possible.

LV makes lvalue subroutines easy and practical to use. It's inspired by the lvalue module which is sadly problematic because of the existence of another module on CPAN called Lvalue. (They can get confused on file-systems that have case-insensitive file names.) LV comes with three different implementations, based on Variable::Magic, Sentinel and tie; it will choose and use the best available one. You can force LV to pick a particular implementation using: $ENV{PERL_LV_IMPLEMENTATION} = 'Magic'; # or 'Sentinel' or 'Tie' The tie implementation is the slowest, but will work on Perl 5.6 with only core modules.

Lexical::Persistence does a few things, all related. Note that all the behaviors listed here are the defaults. Subclasses can override nearly every aspect of Lexical::Persistence's behavior. Lexical::Persistence lets your code access persistent data through lexical variables. This example prints "some value" because the value of $x persists in the $lp object between setter() and getter(). use Lexical::Persistence; my $lp = Lexical::Persistence->new(); $lp->call(\&setter); $lp->call(\&getter); sub setter { my $x = "some value" } sub getter { print my $x, "\n" }

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.

Sub::Exporter is an incredibly powerful module, but with that power comes great responsibility, er- as well as some runtime penalties. This module is a Sub::Exporter wrapper that will let your users just use Exporter if all they are doing is picking exports, but use Sub::Exporter if your users try to use Sub::Exporter's more advanced features features, like renaming exports, if they try to use them. Note that this module will export @EXPORT and @EXPORT_OK package variables for Exporter to work. Additionally, if your package uses advanced Sub::Exporter features like currying, this module will only ever use Sub::Exporter, so you might as well use it directly.