[ruby-core:19776] Re: Proposal: Method#get_args

On Mon, Nov 10, 2008 at 4:26 AM, Meinrad Recheis
<[e-mail]> wrote:
> On Mon, Nov 10, 2008 at 5:32 AM, Austin Ziegler <[e-mail]>
> wrote:
>> On Sun, Nov 9, 2008 at 5:46 PM, Yehuda Katz <[e-mail]> wrote:
>>> I'd like to propose a way to introspect into the arguments of a
>>> method object. Merb uses this feature, which is already available
>>> via ParseTree in 1.8.6, via compile-time in Rubinius, and via
>>> internal structures in JRuby. I'd like to formalize the API so it
>>> can be added to 1.9, which cannot use ParseTree.
>>
>>> The API would return a tuple representing the arguments.
>>
>> Why a tuple, aside from being what's provided by the ParseTree API? I
>> like the idea, I'm just worried that a tuple may be a bit too opaque
>> for something that isn't called often. (We could make it two calls
>> that return a tuple vs. something more descriptive if performance is
>> an issue.) I also was reading not too long ago a section of David
>> Black's forthcoming "Well Grounded Rubyist" that tried to express the
>> different types of parameter lists available in Ruby 1.9 -- how does
>> this return value match up with what's actually possible?
>
> One possibility here would be a class (ie. MethodArgument) modelling a
> method parameter, and having the API return an array of
> MethodArguments:
>
> class MethodArgument
>   def name
>   def position
>   def is_mandatory?
>   def is_block?
>   def is_rest_argument?
>   def to_s <-- return a string that looks like ruby code (i.e. &block
>                for a block parameter that has been named "block")
> end

Yes. I think that would possibly help handle the case of the mandatory
argument after the greedy argument e.g., m(a, b, *c, d, &e) -- and by
having a name of nil, could handle what Matz mentioned about the
anonymous greedy argument, e.g., m(a, b, *). However, a class feels too
heavyweight for the metaprogramming case, while the anonymous tuple
feels a little too lightweight and devoid of context, at least to me.

-austin
-- 
Austin Ziegler * [e-mail] * http://www.halostatue.ca/
               * [e-mail] * http://www.halostatue.ca/feed/
               * [e-mail]