From: Rick DeNatale <rick.denatale@...>
Date: 2007-03-23T20:08:03+09:00
Subject: Re: Ruby Method Signatures (was Re: Multiton in standard library)

On 3/22/07, Paul Brannan <pbrannan@atdesk.com> wrote:
> On Thu, Mar 22, 2007 at 10:26:38PM +0900, Rick DeNatale wrote:
> > >As for the signature, it would have to be a special class of object
> > >that has the qualities of Ruby's arguments -- the ordered list, the
> > >default params and etc. With that object a few things could be
> > >queried, such as arity, maybe a list of parameter names, whether it
> > >has a * parameter or a &block parameter, etc. Importantly it could
> > >output a string representation or the args (whether with the original
> > >names or not). Eg.
> > >
> > >  def a(x,y)
> > >    this.signature.to_s  #=>  "x,y" -or- "a1,a2"
> >
> > This isn't the conventional meaning of signature, which is usually a
> > type construct describing what the caller needs to know about calling
> > the method. A method signature usually contains:
> >
> >   1. The name of the method.
> >   2. The return type (which in Ruby is always anything)
> >   3. The type of each argument (again in Ruby always anything).
> >   4. If needed, an indication of argument optionality.
> >
> > Note that the caller has no need to know the formal argument names.
>
> I agree that the signature must contain at least the above information
> (though it doesn't really need the name, since the name isn't needed to
> call the method).
>
> However, in the spirit of OO, it seems reasonable to allow a signature
> object to contain additional information.  Equality between signatures
> can ignore the extra information, while it can still be available for
> generating a string representation, e.g. for documentation purposes.

My point though is that in common Computer Science terms, methods
signatures, which are a special case of the more general term
signatures don't include  this additional information.

> > I think here that you're really talking about getting at the methods
> > prototype.  Prototypes are like signatures but often include formal
> > argument names.  In a way you can think of them as the source code
> > version of a signature.
>
> Ruby doesn't have prototypes, though.  If a method is defined, it has a
> body.

But it doesn't have signature either.  I was trying to make an analogy.

Trans' suggestion seemed to be to use whatever we call this thing as a
way to reuse the formal parameter list definition from one method in
another.  I don't know that I've seen that in any other language, and
if it exists what it's called. When this is done it's typically
cobbled together with macros and the like.

On reflection though, I don't think that this is a good idea anyway.
Given that Ruby allows dynamic re-definition what should this do?

def foo(x)
   end

 def bar(*=method(:foo).signature)
     p x   # or  p a1
  end

  bar(1)  #=> 1

  def foo(y)
  end

  bar(1) #=> ?

I suppose that the answer is 1, and that the signature is just used as
it is when bar is defined, but then I'm not sure that this is really a
useful feature, it certainly doesn't make the definition of bar EASIER
to read.

> Additionally, a prototype doesn't really contain argument names either.
> In C, for example, it is legal to specify them, but they have no
> meaning.  The argument names only have meaning in the function
> definition (and the names in the definition need not match the names in
> the declaration/prototype).

But they can specify them, whereas signatures in all of the languages
I'm familiar with hold only interface type information.

> Perhaps there is a third word that could be used?

Perhaps.  I'm just suggesting that the term signature has an accepted
meaning and I'd rather avoid defining a special meaning for Ruby.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/