Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration

by MidLifeXis (Monsignor)
on Apr 21, 2013 at 11:15 UTC ( #1029751=perlquestion: print w/replies, xml ) Need Help??
MidLifeXis has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,

This is a redirection of RT Ticket 84769, which is my request for a patch to allow for plugging external modules into CheckDigits::Algorithm.

mamawe, the maintainer of CheckDigits::Algorithm has raised a (valid) concern with my implementation, in that it implements a 'last-requested' short algoritm name to module mapping. The author wanted to take the discussion here for more visibility and input (if I am reading the last update correctly :-).

This node is an anchor point for that discussion.


  • Comment on Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration

Replies are listed 'Best First'.
Re: Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration
by MidLifeXis (Monsignor) on Apr 21, 2013 at 11:25 UTC

    I can see a few approaches to this implementation:

    • Last one in wins (current)
    • First one in wins
    • Last one in wins, but complain loudly
    • First one in wins, unless a --force parameter is provided
    • Something more complex
    mamawe and other monks, what would you think a proper approach would be? I have no preference, other than being able to add a locally-defined module into this framework.

    Reference: RFC: Algorithm::Damm


      My idea is something more complex along the line first one wins, second one gets renamed.

      I think that any module that is already registered under a key should be available with that key while the program is running. And any module wanting to be registered should be registered. This implies that there may be cases when two modules want to be registered with the same key (think of two plugins by different authors). In that case I would register it with another key. To use the second module, the program has to know the new key. Thats why plug_in() should return the real key under which it registered the module.

      The interface could be like this for plugin modules:

      package MyPluginLibA; use Algorithm::CheckDigits; our @EXPORT = qw( CheckDigits ); our @ISA = qw(Algorithm::CheckDigits); our $method = Algorithm::CheckDigits::plug_in('mpla','MyPluginLibA');

      Inheritance and reexport of CheckDigits() is just for convenient use of the plugin module. So the user of the plugin module does not need to use Algorithm::CheckDigits; but can use the interface.

      And then it looks like this for the user of the plugin module:

      use MyPluginLibA; my $cd = CheckDigits($MyPluginLibA::method);

      Algorithm::CheckDigits::plug_in() would only get two arguments, the key and the module name. If the key is already in use, it would find another key to add the module name and return that other key.

      If there is a module that behaves differently for variations of the key (like the module that computes check digits for VISA, AMEX, ISIN, IMEI, ...) it would have to provide a mapping between the intended key and the one returned by Algorithm::CheckDigits::plug_in(). And it should clearly document how to access the different keys.

      Would that be too complex?

      Update: tried to make my intention more clear

        Is it worth while to allow overriding one of the core methods? I am thinking of the ability to inject a checksum algorithm into an application that hardcodes the key.

        Another thought - if overriding an existing checksuming algorithm is to be avoided at all costs, how about just failing in the case of a duplicate, and recommending the plugin module apply a namespace:

        package Algorithm::CheckDigits::Plugin::MyStuff; ... Algorithm::CheckDigits::plug_in( 'MyStuff::method1', 'My::Implementati +on' );
        It should keep the logic simpler (die if exists...) and still allow for a mass import (as in the case of the core modules in the current implementation). The Core:: and unspecified namespace (Core::Foo and Foo) could be declared as reserved for A::CD. Enforcing that declaration is your call (sort of like not mucking around in the internal data structure of an object).

        Since this is your module and my main focus is to be able to tie Algorithm::Damm into the Algorithm::CheckDigits framework, as long as that is the end result, I will defer to you, and my current holdings in round-tuits.

        Note: I found a bug in my implementation where I didn't lc the key on insert. I will apply a fix for that, since it needs to happen no matter what the outcome of the plugin policy for this module ends up being. fixed.

        Update: I also am concerned about the inability of being able to use the same mechanism in the core A::CD framework. It appears that this proposal would require the creation of a registry in each plugin class - at which point I might as well just subclass A::CD and be done with it, as the complexity for the user is pretty much the same. I like the simple syntax for the CheckDigits() call.


Re: Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration
by mamawe (Sexton) on Apr 21, 2013 at 21:13 UTC

    Dear monks,

    I wanted to take the discussion here to get some input from a third and fourth party.

    We could have found a solution by exchanging a few emails back and forth.

    But since this touches the interface of the module I did not want to rush in that matter.

      Would it make sense for you (as the module's owner) to submit this question to It would get a little more visibility.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1029751]
Front-paged by Corion
and nobody stirs...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (9)
As of 2018-05-25 13:33 GMT
Find Nodes?
    Voting Booth?