From: "T. Onoma" <transami@...>
Date: 2003-11-28T02:46:29+09:00
Subject: Re: Method wrapping

On Thursday 27 November 2003 05:45 pm, Christoph wrote:
> 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. 

Also redefining the primary method means you have to know what the next hook 
expects from its output and make sure it gets it:

  def birdy; [1,2,3]; end
  def birdy:wrap; raise !super === Array; end
  def birdy; "1,2,3"; end

If the later just replaces the primary then, bye bye birdy.

> 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.

Beginner-dom? Me too. :-)

> > (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.

And, like i said to Peter, if just the primary method needs a'changin, its a 
good indication that a superclass is needed.

-t0