add methods to allow modification of class and role module names

[djerius]

I'd like to make it easier for the user to specify class and roles names. Mojolicious, for example, allows one to specify roles using a + prefix to indicate the name is relative to some other package.

This commit add two method to Beam::Wire: resolve_class and resolve_role which are passed the specified name and return the fully resolved name. (I created separate versions as there might be different rules for them.)

[coveralls]

Coverage increased (+1.1%) to 93.993% when pulling 330806e on djerius:resolvemodule into 41027e2 on preaction:master.

[preaction]

This sounds like a good feature to add, but I'm not sure I like the idea of adding methods that don't do anything and are meant to be subclassed. I think there's a better way: Fire a configure_service event and allow the event to edit the service's configuration. That way you could have an event handler that edits the service's configuration before it's created and resolve the class/role or indeed do whatever you want.

I'm imagining something like:

use v5.28;
use warnings;
use experimental qw( signatures );
use Beam::Wire;

my $wire = Beam::Wire->new(
    config => {
        service => {
            '$class' => '+Service',
        },
    },
);

$wire->on(
    configure_service => sub ( $wire, $service_name, $config ) {
        if ( $config->{class} ) {
            $config->{class} =~ s/^\+/Local::Project::/;
        }
    },
);

You could still create a subclass if you wanted, and that subclass could use the event:

package My::Wire;
use v5.28;
use Moo;
use experimental qw( signatures );
extends 'Beam::Wire';
sub BUILD ( $self ) {
    $self->on( configure_service => \&_resolve_class );
}
sub _resolve_class ( $wire, $service_name, $config ) {
    ...;
}
1;

Does this sound like it will achieve what you want?

[djerius]

I guess it's a question of style. 99% of the work I do is non-event driven, so it's more intuitive to me to use roles with method modifiers or inheritance to change behaviors. I don't normally associate DI frameworks with events, so it seems a bit foreign to use that approach to modify its behavior.

[preaction]

In my opinion they're functionally the same, but event hooks provide for a (subjectively) cleaner null case and don't require a subclass to add the desired functionality. In a language that lacks anonymous functions and/or first-class subroutines, there's only the subclassing option, but we've got Perl 😄.

Adding an event would also be effectively the same as subclassing and overriding the get_config method, which should work for you as well. If it doesn't, I'm sure some adjustment could be made (and a test written to ensure future compatibility, OO design accounting for subclassing can be hard...)

[preaction]

I've added the events to the module in version 1.023. Did you want to give it a try to see if it works for your case?

[djerius]

I'll give it a whirl shortly. Thanks.