# from Christopher J. Madsen
# on Saturday 15 March 2008 23:43:
>(but I suppose we could redefine our method with a hooked
>
>> wrapper when a hook request appears.)
>
>That's what I'm thinking. When a method is hooked, we define
> something like
>
>sub Module::Build::method_name {
> _call_method_with_hooks(@_, 'method_name')
>}
>
>So we'd have overhead only on the methods that actually got hooked.
>This is made simpler because M::B is essentially an empty class.
The emptiness of M::B is where the platform-specific subclass comes into
play.
So, let's put it is $class, and probably grab a snapshot of the code
ref.
sub create_hook {
my $class = shift;
my ($hook, $blah) = @_;
my $method = $class->can(hand_waving($hook));
$method ||= $class->default_method($hook);
*{$class . '::' . $method} = sub {
lahdeedah($blah, @_); $method->(@_); dahdeelah($blah, @_)
};
}
Though I think some of the plugin loading has to be remembered from
Build.PL-time and reconstructed at each './Build'. Perhaps printing a
subclass would ease that startup pain a bit, but then: reconstruction
might not take long enough to worry about.
--Eric
--
The reasonable man adapts himself to the world; the unreasonable man
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
--George Bernard Shaw
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
