Ok this is how it works. Foo.pm has certain hook subroutines for modifiying the way it behaves. Each plugin is a file which belongs to the same package as Foo.pm and implements one or more of these hooks. Although Foo.pm is object-oriented, I didn't want to make the plugins subclasses because you might have multiple plugins which implement a hook that you might want to call in different places. On one invocation if certain conditions are met I can require Bar.pm and call its' left_hook() subroutine and on a second invocation if other conditions are met, require Blurp.pm and call its' left_hook(). As far as I can tell, you can't have two methods with the same name and signature in the same class so I would have to implement one left_hook() and include the conditional logic there which is not flexible in the long run.
Now you're asking why if Bar.pm and Blurp.pm are installed in the right place, I can't just find them in @INC? The main reason is security. I was thinking paranoidly that what if someone put a module of similiar name to a real plugin which implemented the right type of functions earlier in the @INC path? A different user could be in for unexpected and potentially nasty results. I suppose I could scrub @INC clean but it just seemed easier to define my own fixed directory for plugins.
--
જલધર