I guess you COULD do this:

def meth(n<Integer>, s)
...

where <Integer> is a hint to the runtime to use if present (and not
demanding its presence in most cases).  The 's' does not have a hint of
type, so is excluded from enabling MM stuff.

-rich

> -----Original Message-----
> From: Hal E. Fulton [mailto:hal9000 / hypermetrics.com] 
> Sent: Thursday, September 12, 2002 8:54 AM
> To: ruby-talk ML
> Subject: Re: not grasping the method overloading/multi-dispatch thing
> 
> 
> ----- Original Message ----- 
> From: <dblack / candle.superlink.net>
> To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
> Sent: Thursday, September 12, 2002 7:14 AM
> Subject: Re: not grasping the method overloading/multi-dispatch thing
> 
> 
> > Hi --
> > 
> > On Thu, 12 Sep 2002, Friedrich Dominicus wrote:
> > 
> > > dblack / candle.superlink.net writes:
> > > >
> > > > At a fundamental level, I'm not getting how method 
> signatures and 
> > > > dispatching on type could be "added" to Ruby, such that 
> Ruby was 
> > > > still, so to speak, Ruby.  Among other things, once that option 
> > > > existed, I think we'd see a lot of code where there was 
> only one 
> > > > version of a method, but it was still typed.
> > >
> > > As Matz pointed out overloading would be in the spirit of Ruby
> > 
> > Right, but that's the part I don't get :-)  I'm picturing 
> things like:
> > 
> >   def meth(Integer n, String s)
> >   ...
> >   def meth(Float f, String s)
> >   ...
> > 
> > and somewhere along the line I'm not clear on how that fits 
> into the 
> > spirit/design/philosophy of Ruby.
> 
> My opinion: It just doesn't.
> To declare variables at all is not Rubyish IMO
> (especially when assigning types, which can be
> a separate issue).
> To create a method signature by assigning types
> to parameters is even worse, as far as I can see.
> It looks like a huge step backward toward Java
> and C++.
> 
> Hal
> 
> 
> 
>