Perhaps the simplest method would be to have your main module define stubs for those methods that you want to parcel off into other submodules.

Something like (Untested. I may have the details wrong, its not something you use every day):

sub addition { ## stub
    no strict 'refs';
    require 'Date::Math::Add';
    *addition = \&Data::Math::Add::addition;
    goto &addition;
}
[download]

The first time the stub method is called, it dynamically requires the sub module and then fixes up the linkage by replacing its own reference with that of the method from the newly loaded module; before finally transferring control (via the special goto) to the loaded method.

Subsequent calls would go directly to the loaded method.

And I really don't see any benefit to doing that in 99% of cases. (The other 1% is when you have methods which are sufficiently expensive to compile that you don't want their source code to be processed if the method isn't going to actually be used.)

It seems like it would be a lot more straightforward to just put all the code into a single module (and a single class).

That said, there are definitely ways to do the sort of thing you're asking about. The core Perl language provides the AUTOLOAD keyword to dynamically pull in (or generate) the source of not-yet-defined methods on demand. There are also several fine CPAN modules for handling plugins; I personally use all for simple plugin handling and Module::Pluggable for more complex cases.

Hi TorontoJim,

I would compose in my methods with roles. I use Moo and Moo::Role:

In MyClass.pm -

package MyClass;

use Moo;
with 'MyClass::Child';

sub foo { return 'foo'; }

1;
[download]

package MyClass::Child;

use Moo::Role;

sub foo { die 'horribly'; }
sub bar { return 'bar'; }

1;
[download]

#!/usr/bin/perl
use strict; use warnings; use feature 'say';
use MyClass;

my $obj = MyClass->new;
say $obj->foo;
say $obj->bar;

__END__
[download]

$ perl 1158279.pl
foo
bar
[download]

You could also use Role::Tiny directly, but with Moo you'll of course get access to the other sugar like not having to write a constructor, type-checking, etc.

If you have a whole bunch of roles and for some reason they are expensive to compile you can load them conditionally with with and eval, say based on arguments passed to the constructor call:

package MyClass;
use Moo;

sub BUILD {
    my ( $self, $args ) = @_;

    my %modules = (
        1 => 'MyClass::MyChild',
        0 => 'Acme::Frobnicate',
    );

    my $module = $modules{ $args->{'be_serious'} };
    eval "with '$module'; 1;" or die $@;

    return $self;
}           

sub foo { return 'foo'; }

1;
[download]

As far as whether you should be rethinking what you're doing, there's certainly no harm in reinventing a wheel as an academic exercise ... but I would look at the DateTime project (maybe especially DateTime.pm#How_DateTime_Math_Works), Date::Calc, even Time::Piece before I put too many CPU cycles into tackling date math. I'd also recommend against releasing any code under the Date::Math namespace, until you're very sure that it's at least as reliable as the aforementioned modules.

Hope this helps!

Instead of evaling a with, you can also apply_roles_to_package or apply_roles_to_object .

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Thanks choroba, I didn't know about those Role::Tiny methods.

I am not sure about whether I prefer them to eval "with '$module'; 1;", though.

I had to load Role::Tiny explicitly not importing anything, since its before(), after(), around() and with() methods clash with Moo's :

Subroutine MyClass::before redefined at [...]/5.22.0/Role/Tiny.pm line
+ 58.
Subroutine MyClass::after redefined at [...]/5.22.0/Role/Tiny.pm line 
+58.
Subroutine MyClass::around redefined at [...]/5.22.0/Role/Tiny.pm line
+ 58.
Subroutine MyClass::with redefined at [...]/5.22.0/Role/Tiny.pm line 6
+7.
[download]

And even when I do that I can't use apply_roles_to_object() inside sub BUILD, because the parent's methods haven't been loaded and thus the child's will be.

package MyClass::Child;

use Moo::Role;

sub foo { die 'horribly'; }
sub bar { return 'bar'; }

1;
[download]

package MyClass;

use Moo;
use Role::Tiny();

sub BUILD {
    my $self = shift;

    Role::Tiny->apply_roles_to_object( $self, 'MyClass::Child' );

    return $self;
};

sub foo { return 'foo'; }

1;
[download]

Output:

$ perl -MMyClass -E '$o = MyClass->new; say $o->foo, $o->bar;'
horribly at MyClass/Child.pm line 5.
[download]

So the only way I could make it work as part of the Moo constructor was with apply_roles_to_package() :

package MyClass;

use Moo;
use Role::Tiny();

sub BUILD {
    my $self = shift;

    Role::Tiny->apply_roles_to_package( __PACKAGE__, 'MyClass::Child' 
+);

    return $self;
};

sub foo { return 'foo'; }

1;
[download]

Output:

$ perl -MMyClass -E '$o = MyClass->new; say $o->foo, $o->bar;'
foobar
[download]

Thanks again for the pointer.



The way forward always starts with a minimal test.

Thank you for your responses. Yes, this is an academic exercise on my part, learning how to do this. I've written custom modules for years for proprietary implementations, but I've never written a parent/child scenario before. This is my attempt to learn it as date math is easy, it's the getting things to work how I want ... or changing how I want them to work ... that is the learning curve.