Re^2: Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration

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

Comment on Re^2: Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration Select or Download Code

Replies are listed 'Best First'.
Re^3: Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration by MidLifeXis (Monsignor) on Apr 21, 2013 at 18:28 UTC
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	[reply] [d/l] [select]
Re^4: Plugin Overwriting or saving keys in Algorithm::CheckDigits configuration by mamawe (Sexton) on Apr 21, 2013 at 21:30 UTC
My thoughts about overriding are in the update above your post I would rather try to make the interface reasonable and easy to use. Then I would keep the logic as simple as possible within the constraints of the interface For mass imports there could be another function, but any plugin using this should document that it could fail in some circumstances I suggest we'll wait a few days for opinions from the other monks and then implement a plugin structure.	[reply]