From: Austin Ziegler Date: 2008-11-10T21:50:32+09:00 Subject: [ruby-core:19776] Re: Proposal: Method#get_args On Mon, Nov 10, 2008 at 4:26 AM, Meinrad Recheis wrote: > On Mon, Nov 10, 2008 at 5:32 AM, Austin Ziegler > wrote: >> On Sun, Nov 9, 2008 at 5:46 PM, Yehuda Katz 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 * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca