On Oct 11, 2007, at 21:55 , Charles Oliver Nutter wrote:
> Eric Hodel wrote:
>> The information is there, but I don't see a way to automatically  
>> make sure it is correct for MRI/YARV.
>> I don't think this is an area where you need to maintain  
>> compatibility.
>>> What good does Method#arity do if it isn't the actual arity being  
>>> enforced? From the Ruby side, it doesn't help to know the C arity  
>>> number. In JRuby now, every method stores required arg count,  
>>> optional arg count, and whether rest args or a block arg are  
>>> accepted, and those values are used to calculate the appropriate  
>>> arity.
>> I agree that its not helpful for the C methods.  It would be easy  
>> to fix, but I don't know how to automate it so that it is always  
>> correct.
>>> Is it not possible to get -2, -3, -4 etc arities from Method#arity?
>> Currently, for ruby methods you can get -2, -3, etc, for C methods  
>> you can only get -1.  See method_arity() in eval.c
>
> [...]
>
> Couldn't the C code also bind methods this way, specifying the  
> correct arity at bind time? It doesn't seem like arities would  
> change that often.
>
> FWIW, an example method, equivalent to rb_ary_aref:
>
> @JRubyMethod(name = "[]", name2 = "slice", required = 1, optional = 1)
> public IRubyObject aref(IRubyObject[] args) {
>  ...
>
> With this annotation, binding the Java method to both names and  
> enforcing appropriate arity is all automatically generated.

NODE_CREF could have nd_argc holding the calling convention as it  
does now, and add an nd_arity (stored in u3.cnt) storing the Ruby arity.

The arity would be provided to rb_define_method:

rb_define_method(rb_cString, "[]", rb_str_aref_m, -1, -2);

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars