From: Rick DeNatale Date: 2007-03-23T22:41:32+09:00 Subject: Re: Ruby Method Signatures (was Re: Multiton in standard library) On 3/23/07, TRANS wrote: > On 3/23/07, Rick DeNatale wrote: > > 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? Something like this might work, the only glitch is methods like def foo(d=1) which have an arity of -1 indicating that they have a variable number of arguments, but this doesn't indicate that they have an upper limit on the number of arguments. But I think that it gets close: module PlistGenerator def plist # the arity is a positive number if all arguments are required # otherwise it is -1-number_of_required arguments # n = -1 - required # required + n = -1 # required = -1 -n n = arity req_ct = n >= 0 ? n : -1 - n args = (1..req_ct).map {|num| "a#{num}"} args << "*opt" if n < 0 args.join(',') end end class Method include PlistGenerator end class UnboundMethod include PlistGenerator end -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/