LRC - Perl interface for longitudinal redundancy check generation
The Longitudinal Redundancy Check (LRC) is a one byte character,
commonly used as a byte-field in data transmission over analog systems.
Most commonly, in STX-ETX bounded strings sent in financial protocols.
Following some previous experience with such protocols, I wrote
an LRC function in perl and later decided to re-write in C
for efficiency. The result is this module String::LRC,
which generates this aforementioned byte.
Commonly used in financial protocols as follows with ETX (ASCII 03)
appended to LRC sum and packets after the STX (ASCII 02), payload,
and ETX chars.
The String::Parity module for perl5 may be used to generate and test
even, odd, mark and space parity on arbitrary strings.
String::TT exports a "tt" function, which takes a TT (Template Toolkit)
template as its argument. It uses the current lexical scope to resolve
variable references.
Struct::Dumb creates record-like structure types, similar to the struct keyword
in C, C++ or C#, or Record in Pascal. An invocation of this module will create a
construction function which returns new object references with the given field
values. These references all respond to lvalue methods that access or modify the
values stored.
It's specifically and intentionally not meant to be an object class. You cannot
subclass it. You cannot provide additional methods. You cannot apply roles or
mixins or metaclasses or traits or antlers or whatever else is in fashion this
week.
On the other hand, it is tiny, creates cheap lightweight array-backed
structures, uses nothing outside of core. It's intended simply to be a slightly
nicer way to store data structures, where otherwise you might be tempted to
abuse a hash, complete with the risk of typoing key names. The constructor will
croak if passed the wrong number of arguments, as will attempts to refer to
fields that don't exist.
This module does a compile-time code injection to let you define subroutine
aliases based on its name.
This differs from p5-Sub-Name in that it defines a typeglob in a more correct
way and keeps you from manipulating the symbols table directly. You can use
the subroutine as if it was defined the ordinary way then.
This is particularly useful in the cases when you need to have several
identical subroutines with different names.
Sub::Exporter::ForMethods is helper routines for using Sub::Exporter
to build methods.
Sub::Exporter::GlobExporter - export shared globs with Sub::Exporter collectors
Sub::Exporter::Lexical provides an alternate installer for Sub::Exporter.
Installers are documented in Sub::Exporter's documentation; all you need to know
is that by using Sub::Exporter::Lexical's installer, you can import routines
into a lexical scope that will be cleaned up when that scope ends.
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.
The biggest benefit of Sub::Exporter over existing exporters (including the
ubiquitous Exporter.pm) is its ability to build new coderefs for export, rather
than to simply export code identical to that found in the exporting package.