From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-11-27T22:55:07+09:00
Subject: Re: Method wrapping

> I have asked the same this question as well and I really wish
> you could reconsider this(= leave the stack hook method
> stack in place).
>
> Firstly, you pretty much have to kill this stack if the signature
> of the primary method was changed since the signatures of
> hook methods written for the old primary method can't be
> used anymore.
>
> Secondly, if I changed the primary leaving "pre'', "post'' and
> "wrap" conditions often makes little semantic sense so they
> should always be killed.
>
> Maybe a comprise of leaving the stack in place if the signature
> didn't change and killing it if the signature of primary method
> Changed, or as you indicated, if the primary method was removed
> altogether is most flexible approach?

I think Matz's way is the best compromise. Besides, if you only add
arguments to methods or slightly change (duck) type of some arguments,
you'll often be safe with an approach like this:

def foo:wrap(a1, a2, *a)
  do_something_with(a1, a2)
  p "logging call to foo(#{a1}, #{a2}, #{a.join(', ')})"
  result = super
  p "result = #{result}"
  result
end

Removing hooks on change of a method means all hooks have to be added
again needlessly in some cases. And if a change is incompatible with the
hooks, you can remove or redefine them yourself once there's an API to do
so. And my guess is it will be less work to remove hooks manually than to
add hooks manually because if you're careful most hooks remain valid. And
besides, on large changes to signatures of methods, you'll have a lot of
work to adapt the rest of the code anyhow.

Peter