On 3/23/07, Rick DeNatale <rick.denatale / gmail.com> wrote:
>
> 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.

Thats' true. The real need though is just so we can define method
wraps with the same arity. That's the useful part. How else could we
go it?

(Oh, and the use of an object for "this" rather than a bunch of
methods like __callee__, that's aside, but better idea IMHO too).

T.