On Thu, Mar 13, 2003 at 12:02:22AM +0000, Piers Cawley wrote: > Damian Conway <[EMAIL PROTECTED]> writes:
> > We didn't include it in A6 but our current notions (i.e. this week ;-) > > about interactions between subs, methods, and multimethods are > > something like this: > > > > Dispatched to first existing > > Call and visible of... > > ==================== ============================ > > > > foo($x, $y); 1. C<sub DISPATCH> > > 2. C<multi DISPATCH> > > 3. C<sub foo> > > 4. C<sub AUTOLOAD> > > 5. C<multi foo> > > 6. C<multi AUTOLOAD> [snip similar methods] > This looks like a classic Chain of Responsibility pattern. I wonder, > would it be possible to expose the dispatch system as an object > (chain) which could be modified by the courageous programmer so that > one could, for instance, set up a different dispatcher for the rest of > a lexical scope which dispatched to multimethods before subs/methods? > > I know you could override it by implementing your own DISPATCH sub, > So, even if there isn't a 'core' way of manipulating the current > dispatcher it's possible to write a module that would make it look > like you could. I think that it would be nice to be able to chain yourself in there, rather than having to replace. In perl5 there are some things you have to override, rather than adding to. Offhand I can't see a practical way that the opcode loop or the regexp engine could be done in any other way, but IIRC require is hookable, and UNIVERSAL::AUTOLOAD and the core ops have to be replaced, when what you might like to do is just wrap to extend things. Or will wrapping these routines be good enough? Sort of related - if you wrap a subroutine, and then something else wraps the subroutine (and hence wraps you), can you pull your wrapper off without everything getting confused? (ie their wrapper now directly wraps the original) ie if Acme::Foo wraps &DISPATCH, then Acme::Bar is loaded at it wraps &DISPATCH, then the script removes Acme::Foo, is the wrapping now as if only Acme::Bar was the only module ever loaded? Nicholas Clark
