Re: Plugin architecture

Eric Wilhelm wrote:
> # from Christopher J. Madsen
> # on Sunday 16 March 2008 23:37:
>> I was saying that if a pre hook returns anything other than 'done' or
>> 'continue', then the plugin manager reports "Invalid return value
>> from ...".  In other words, it's a bug in the plugin, which the
>> plugin manager will catch and report.
> 
> I'm still not convinced that the return values have enough significance 
> to warrant that kind of stricture.  At least, not for ACTION_* methods.
> 
> For all other methods, the continue/done return really seems like it 
> would get in the way, but I still don't have a clear picture of how 
> pre_/post_ hooks for regular methods would be used (and/or made to 
> work.)

There are two separate concepts here:  the return value from the hook 
function, and the return value from the method being hooked.

A pre hook can do two different things:

1. It can take over for the method (preventing the normal method from 
being called.  This is the 'done' case.  It's equivalent to a subclass 
doing:

   sub method { ...do stuff...;  return $value }

2. It can do stuff (possibly munging @_) and then allow the normal 
method to operate.  This is the 'continue' case.  It's equivalent to a 
subclass doing:

   sub method { ...do stuff...; (shift @_)->SUPER::method(@_) }

Obviously, you don't have to use the return value to indicate this; 
that's just what I picked for my initial design.  But you need to have 
some way of indicating whether the normal method should be called.

For example, in pre_ACTION_test, this is the difference between "I want 
to do some stuff before the tests begin" ('continue') and "I want to do 
all the testing myself" ('done').

Post hooks don't get this choice, because they operate after the normal 
method has been called.

-- 
Chris Madsen                                          [email protected]
   --------------------  http://www.cjmweb.net  --------------------