Re: Plugin architecture

# 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
---------------------------------------------------