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

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');
[download]

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);
[download]

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' );
[download]

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.

--MidLifeXis

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 http://prepan.org/? It would get a little more visibility.

--MidLifeXis