Hi --

On Mon, 4 Oct 2004, Brian Candler wrote:

> On Mon, Oct 04, 2004 at 11:08:42PM +0900, trans.  (T. Onoma) wrote:
> > Agreed. The reason I've gone the other way is b/c of this kind of thing:
> > 
> >   def ducky_method(a,b,c,d,e)
> >   end
> > 
> >   ...
> > 
> >   case method(:ducky_method).arity
> >   when 5
> >   when 4
> >   when 3
> >   ...
> 
> Ugh... fortunately I've never had to write code like that :-) Especially
> with the nasty overloading of negative values: -3 means 2..infinity. (Or is
> it 4..infinity? I have to think about it every time. Remember, -1 means 0 to
> infinity, obviously. So -3 is 2 to infinity. Got that?)
> 
> Anyway, I would hope that those methods would be declared as
> 
>   def ducky_method(a,b,c)
>   def ducky_method(a,b,c,d=99)
>   def ducky_method(a,b,c,d=99,e=123)
> 
> and that you would therefore know that a call with 3 parameters makes sense.
> Otherwise, perhaps those methods should have completely different names, if
> they do different things altogether (i.e. if it has two legs it's a goose,
> if it has 4 legs it's a mongoose)

I have to admit (and my lack of C++, Java, etc. is probably showing
through here -- i.e., I'm perfectly willing to believe there's
something fundamental I'm just missing), I have never understood the
idea of differentiating methods by number of arguments.  To me it's
sort of like differentiating them based on what letters the argument
names begin with.  What if two slightly different forms of the method
both, by chance, took three arguments?  Would one add a dummy
argument?  The whole thing has always seemed to me like a
gimmick/workaround for languages with design problems.  

(Again, all based on gut reaction and probably not enough
education....) 


David

-- 
David A. Black
dblack / wobblini.net