Certain applications like to defer the decision to use a particular
module till runtime. This is possible in perl, and is a useful trick in
situations where the type of data is not known at compile time and the
application doesn't wish to pre-compile modules to handle all types of
data it can work with. Loading modules at runtime can also provide
flexible interfaces for perl modules. Modules can let the programmer
decide what modules will be used by it instead of hard-coding their
names.
require EXPR only accepts Class/Name.pm style module names, not Class::Name.
How frustrating! For that, we provide load_class 'Class::Name'.
It's often useful to test whether a module can be loaded, instead of throwing
an error when it's not available. For that, we provide try_load_class
'Class::Name'.
Finally, sometimes we need to know whether a particular class has been loaded.
Asking %INC is an option, but that will miss inner packages and any class for
which the filename does not correspond to the package name. For that,
we provide is_class_loaded 'Class::Name'.
This module provides a 'Local Mean Time' timezone for DateTime. Using it you
can determine the Mean Time for any location on Earth. Note however that the
Mean Time and the Apparent Time (where the sun is in the sky) differ from day
to day. This module may account for Local Apparent Time in the future but then
again, the Solar:: modules will probably be a better bet.
If you want more information on the difference between LMT and LAT, search the
www for 'equation of time' or 'ephemeris'.
File::NFSLock - perl module to do NFS (or not) locking.
The module is based of concept of hard linking of files being atomic
across NFS. This concept was mentioned in Mail::Box::Locker (which was
originally presented in Mail::Folder::Maildir). Some routine flow is
taken from there -- particularly the idea of creating a random local
file, hard linking a common file to the local file, and then checking
the nlink status. Some ideologies were not complete (uncache mechanism,
shared locking) and some coding was even incorrect (wrong stat index).
File::NFSLock was written to be light, generic, and fast.
Mac::FileSpec::Unixish provides two functions, `nativize' and `unixify'
(both of which are exported by default), that will allow you to denote
and manipulate pathspecs in Unixish style, and let you convert these
pathspecs to and from the native OS's format for conveying such things.
It currently assumes that if you are not running under MacOS (as
reported in `$^O'), you must be on a Unix box. If you want better, use
File::Spec -- in essence, Mac::FileSpec::Unixish is a cheap hack to get
around using File::Spec.
This is a utility that creates common Moose subtypes, coercions and option
specifications useful for dealing with Path::Class objects as Moose attributes.
This module constructs coercions (see Moose::Util::TypeConstraints) from both
'Str' and 'ArrayRef' to both Path::Class::Dir and Path::Class::File objects.
It also adds the Getopt option type ("=s") for both Path::Class::Dir and
Path::Class::File (see MooseX::Getopt).
This is just meant to be a central place for these constructs, so you don't
have to worry about whether they've been created or not, and you're not tempted
to copy them into yet another class (like I was).
Resources are a way to specify information of interest to program or
packages.
Applications use resource files to specify and document the values of
quantities or attributes of interest.
Resources can be loaded from or saved to resource files. Methods are
provided to search, modify and create resources. Packages use resources to
hardwire in their code the default values for their attributes, along with
documentation for the attributes themselves.
Packages inherit resources when subclassed, and the resource names are
updated dynamically to reflect a class hierarchy.
Methods are provided for interactive resource inspection and editing.
This is a specialized POD viewer to extract embedded tests and code
examples from POD. It doesn't do much more than that. pod2test does the
useful work.
After creating a Pod::Tests object, you parse the POD by calling one of
the available parsing methods documented below. You can call parse as many
times as you'd like, all examples and tests found will stack up inside the
object.
Once extracted, the tests can be built into stand-alone testing code using
the build_tests() and build_examples() methods. However, it is recommended
that you first look at the pod2test program before embarking on this.
Test::Class provides a simple way of creating classes and
objects to test your code in an xUnit style.
Built using Test::Builder it is designing to work with
other Test::Builder based modules (Test::More,
Test::Differences, Test::Exception, etc.)
Note: This module will make more sense if you are already
familiar with the "standard" mechanisms for testing perl code.
Those unfamiliar with Test::Harness, Test::Simple, Test::More
and friends should go take a look at them now.
Note: This is an early release. Things may change. Be warned.
Java-Readline is a port of GNU Readline for Java. Or, to be more
precise, it is a JNI-wrapper to Readline. It is distributed under the
LGPL.
You must call Readline.load(ReadlineLibrary lib); before using any
other methods. If you omit the call to the load()-method, the pure
Java fallback solution is used. Possible values for lib are:
ReadlineLibrary.PureJava
ReadlineLibrary.GnuReadline
ReadlineLibrary.Editline
ReadlineLibrary.Getline
Note that all programs using GnuReadline will fall under the GPL,
since Gnu-Readline is GPL software!