Ports 搜索

Essentially, this module is a very optimized version of Clone::More. By taking advantage of one of Clone::More's 'OPTIMIZATION_HACKS' as well as removing all the Pure Perl from the More.pm, I was able to gain a lot of speed out of the module. Essentially, though, the core of the module is exactly as that of Clone::More. You will see that by using Benchmark::cmpthese, I ran a simple comparison between Storable::dclone, Clone::More::clone, and Clone::Fast::clone. You will (should) begin to see the reason why I loaded this module along side of Clone::More. Rate Storable Clone::More Clone::Fast Storable 7552/s -- -39% -59% Clone::More 12400/s 64% -- -33% Clone::Fast 18442/s 144% 49% -- For more information relative to the DESCRIPTION of this module, I recommend peeking into the POD written for Clone::More (I took more time with it ;) )

The Devel::Required module only serves a purpose in the development environment of an author of a CPAN module (or more precisely: a user of the ExtUtils::MakeMaker module). It makes sure that any changes to the required modules specified in the Makefile.PL are automatically reflected in the appropriate text file and in the appropriate source files (either explicitly or implicitly specified). It takes the information given with the PREREQ_PM parameter and by default writes this to the README file, as well as to the POD of the file specified with the VERSION_FROM parameter. Both these defaults can be overridden with the "text" and "pod" parameters in the use Devel::Required specification.

This defines the policy for file I/O with modules such as File::Slurp::WithinPolicy. The purpose is to allow systems administrators to define locations and restrictions for applications' file I/O and give app developers a policy to follow. Note that the module doesn't ENFORCE the policy - application developers can choose to ignore it (and systems administrators can choose not to install their applications if they do!). You may control which policy gets applied by creating a File::Policy::Config module with an IMPLEMENTATION constant. You may write your own policy as a module within the File::Policy:: namespace. By default (if no File::Policy::Config is present), the File::Policy::Default policy gets applied which doesn't impose any restrictions and provides reasonable default locations for temporary and log files.

This module is a wrapper around Getopt::Long that extends the value of the original Getopt::Long module to: 1) add a simple graphical user interface option screen if no arguments are passed to the program. 2) provide an auto-help mechanism such that -h and --help are handled automatically. It's designed to make the creation of graphical shells trivial without the programmer having to think about it much as well as providing automatic good-looking usage output without the programmer needing to write usage() functions. This also can turn normal command line programs into web CGI scripts as well (automatically). If the Getopt::GUI::Long program is installed as a CGI script then it will automatically prompt the user for the same variables.

IPC::Open3::Simple aims at making it very easy to start a shell command, eventually feed its stdin with some data, then retrieve its stdout and stderr separately. When you want to run a shell command and parse its stdout/stderr or feed its stdin, you often end up using IPC::Run, IPC::Cmd or IPC::Open3 with your own parsing code, and end up writing more code than you intended. IPC::Open3::Simple is about removing this overhead and making IPC::Open3 easier to use. IPC::Open3::Simple calls IPC::Open3 and redirects stdin, stdout and stderr to some function references passed in argument to the constructor. It does a select on the input/output filehandles returned by IPC::Open3 and dispatches their content to and from those functions.

IO::Event provides an object-based callback system for handling nonblocking IO. The design goal is to provide a system that just does the right thing without the user needing to think about it much. All APIs are kept as simple as possible yet at the same time, all functionality is accesible if needed. Simple things are easy. Hard things are possible. Most of the time file handling syntax will work fine: <$filehandle> and print $filehandle 'stuff'. IO::Event provides automatic buffering of output (with a callback to throttle). It provides automatic line-at-a-time input. After initial setup, call IO::Event::loop(). IO::Event was originally written to use Event. IO::Event still defaults to using Event but it can now use AnyEvent or its own event loop.

Inline::TT provides Inline access to version 2.0 and higher of the Template Toolkit. This allows you to house your templates inside the source code file, while retaining the ability to cache compiled templates on the disk (via Inline's caching mechanism). The names of the blocks in the template are exported as functions. Call these with a reference to a hash of values, which will be used for interpolation in the templates. This hash reference is the same as the second argument to the process method of any Template object. The output from template toolkit will be returned to you as a single string. Note that leading and trailing spaces are trimmed, further the template toolkit options PRE_CHOMP and POST_CHOMP are set. Currently, there is no way to change these behaviors.

POE::Session::MultiDispatch is a drop in replacement for POE::Session that adds callback dispatch functionality to POE sessions. Each event may have multiple handlers associated with it. Fine control over the order of execution is available using helper methods that extend the interface of a POE::Session. POE::Session::MultiDispatch uses POE::Session as a base class. When multiple callbacks are registered for an event, only the last callback survives, all the others are clobbered. POE::Session::MultiDispatch is much nicer to your registered callbacks, it keeps them all in the order they were defined. When an event is triggered, all the callbacks are then executed in that same order (unless you muck around with said order).

The Perl garbage collector uses simple reference counting during the normal execution of a program. This means that cycles or unweakened references in other parts of code can keep an object around for longer than intended. To help avoid this problem, the reference count of a new object from its class constructor ought to be 1. This way, the caller can know the object will be properly DESTROYed when it drops all of its references to it. Test::Refcount provides two test functions to help ensure this property holds for an object class, so as to be polite to its callers. If the assertion fails; that is, if the actual reference count is different to what was expected, a trace of references to the object can be printed, if Marc Lehmann's Devel::FindRef module is installed. This may assist the developer in finding where the references are.

This module adds the ability to quickly create new types of tie objects without creating a complete class. It does so in such a way as to try and make the programmers life easier when it comes to single-use ties that I find myself wanting to use from time-to-time. The Tie::Simple package is actually a front-end to other classes which really do all the work once tied, but this package does the dwimming to automatically figure out what you're trying to do. I've tried to make this as intuitive as possible and dependent on other bits of Perl where I can to minimize the need for documentation and to make this extra, extra spiffy.