view release on metacpan or  search on metacpan

lib/Algorithm/CheckDigits.pm  view on Meta::CPAN

=item iban

See L<Algorithm::CheckDigits::M97_002>.

=item upc

See L<Algorithm::CheckDigits::MBase_001>.

=item blutbeutel, bzue_de, ustid_de, vatrn_de

See L<Algorithm::CheckDigits::MBase_002>.

=item sici

See L<Algorithm::CheckDigits::MBase_003>.

=item pa_de

See L<Algorithm::CheckDigits::MXX_001>.

=item cas

See L<Algorithm::CheckDigits::MXX_002>.

=item dem

Old german bank notes (DEM), see L<Algorithm::CheckDigits::MXX_003>.

=item ustid_at, vatrn_at

See L<Algorithm::CheckDigits::MXX_004>.

=item esr9_ch

See L<Algorithm::CheckDigits::MXX_005>.

=item verhoeff

Verhoeff scheme, see L<Algorithm::CheckDigits::MXX_006> or
L<Algorithm::Verhoeff>

=back

=head2 EXPORT

This module exports the Function C<CheckDigits()> that is used to create an
instance of a checker with the given algorithm.

=head1 REGISTERING PLUGINS

Brian T. Wightman was the first, asking me to add a plugin registry to
Algorithm::CheckDigits and so I added the function C<plug_in()> that does just
this, registering plug in modules to be used just like the modules in the
distribution of this module.

Providing some means to add additional algorithms without the need to change
the module has the benefit that the user of those additional algorithms may
easily use them with the same interface as the other algorithms without having
to wait for a new version, that may or may not include the wanted algorithm.

But there is a problem: the user must be able to select the new algorithms
like he did with the other ones. And the catch is: since these new algorithms
are developed independently there is no guarantee that no more than one
module applies for the same handle. I could have implemented some simple
strategies like last one wins (the module that registers last for a given
handle is the one that is choosen) or first one wins (the first registered
module is choosen). Instead I went for something more complex to assure that
every module that wants to get registered will be registered and that every
registered module will be accessible by the same handle as long as the program
runs. To make this work C<plug_in()> sees the third argument only as a hint
how the handle should look like, when a module is registered. It returns the
real handle with which the algorithm can be instantiated. That means a
developer of a plugin module cannot make the handle immediately available like
I did for the modules in the distribution. Instead there should be something
like a public variable or function that returns the handle as it came back
from the C<plug_in()> function.

This could go like this in the module:

 package Algorithm::XyZ;

 use Algorithm::CheckDigits;

 our $xyz = Algorithm::CheckDigits::plug_in('Algorithm::XyZ',
                                            'XyZ check digits',
                                            'xyz');

And the user of this algorithm would write something like this:

 use Algorithm::CheckDigits;
 use Algorithm::XyZ;

 my $cd = CheckDigits($Algorithm::XyZ::xyz);

 if ($cd->is_valid($some_number)) {
     # do something
 }

Please have a look at the plugin tests in the test directory (I<t/plugin*.t>)
and the accompanying modules (I<t/PluginLib*.pm>) for example usage. You may
also try to load an additional module with the scripts in I<bin> and
I<cgi-bin> and look for the additional algorithms in the output:

 perl -Ilib -It -MPluginLibA bin/checkdigits.pl list

 perl -Ilib -It -MPluginLibA cgi-bin/checkdigits.cgi

=head2 Namespace

I would like to ask you to use any namespace below or outside but not direct
Algorithm::CheckDigits. That means for instance for the XyZ algorithm,
Algorithm::XyZ would be fine, Algorithm::CheckDigits::Plugin::XyZ or
Algorithm::CheckDigits::X::XyZ would be fine too. But
Algorithm::CheckDigits::XyZ could collide with some future version of the
Algorithm::CheckDigits distribution, so please avoid this namespace.

=head1 SEE ALSO

L<perl>,
F<www.pruefziffernberechnung.de>.