From: Christoph <chr_mail@...>
Date: 2003-11-28T01:45:11+09:00
Subject: Re: Method wrapping

Peter wrote:
...
> If the arity goes up, you can avoid problems provided the 
> first arguments remain the same and your hook doesn't care 
> about them by using a *arg as in my example...
> 
> > I feel you gave only very weak argument why in this particular 
> > circumstance the removal shouldn't happen  automatically.
> 
> OK, I didn't realize your argument was in case of arity 
> changes, just like you didn't realize my argument was for the 
> general case. Cool! But seriously, if that particular 
> circumstance is rare enough, why care?

You realize that you on are speculative grounds claiming that
these circumstances will be rare enough. One of the more common 
method redefining circumstances  are probably (this base on other
evidence but my gut feeling:-) are of the form

def meth(a,b,c,new_parm = some_default_value)  
	....
end

Even if this were to happen rarely, redefining the primary method
in an arity altering way would render the class unusable if the
hooks weren't removed.  Being forced to use reflection features to
remove the hooks is NOT suitable for beginners and I wouldn't want 
to be bothered (perhaps because I never grew nor ever will grow out
of beginner-tum:-)  with this either.

> (Gee, they already brainwashed me :-) So you still need to 
> show that a change in arity happens often enough compared to 
> say change of implementation. I think that highly depends on 
> how you write your code, whether you work top-down - first 
> get the interfaces right, then implement
> - or bottom-up - start implementing small parts and build on 
> that to make larger parts. Or whether you combine both.
> 
> Also, if you'd change a method and need extra arguments for 
> extra functionality, then if your hook can't handle those 
> extra arguments generically, that's pretty tight coupling, isn't it?

Only if suspect that potential customers are likely to redefine
the primary method signature.

/Christoph