Re: Ruby Method Signatures (was Re: Multiton in standard library)

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.

In nodewrap, the signature objects I keep hold the following
information:

  - origin class (MyClass)
  - method name (foo)
  - argument names (a, b, c, rest, block)
  - argument default values (c=42+d)
  - rest arg (*rest)
  - block arg (&block)

Thus a string representation can be generated:

  MyClass#foo(a, b, c=42+d, *rest, &block)

I've ignored the equality issue, but I should probably address that.

> So it still seems to me that a Ruby type signature only has the name
> of the method (which I missed in my opening post), and something like
> the arity, although it needs to be cleaned up in the case of arguments
> with default values.

Some cfuncs can only take objects of a certain type (otherwise you'll
get an exception), so a type signature ideally should take that into
account.  But there's no good way of obtaining that information.

The return type can often be gleaned from the ri documentation, but
argument types aren't consistently represented.

> >A bonus would be to use the arguments in place of actual arguments
> >when defining a method.
> >
> >  def foo(x)
> >  end
> >
> >  def bar(*=method(:foo).signature)
> >    p x   # or  p a1
> >  end
> >
> >  bar(1)  #=> 1
> >
> >The *= is needed b/c there has to a special way to indicate that.
> 
> 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.

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

Perhaps there is a third word that could be used?

Paul