T. Onoma
11/27/2003 5:46:00 PM
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