On Monday, Apr 7, 2003, at 22:40 America/Denver, Dave Thomas wrote:
> On Monday, April 7, 2003, at 11:01 PM, Michael Granger wrote:
>> It's also convenient when you are testing for a method object and you 
>> don't care whether it's bound or unbound:
>>
>>   obj.is_a?( Method )
>>
>> whereas if one weren't a generalization of the other, you'd have to 
>> do:
>>
>>   obj.is_a?(Method) || obj.is_a?(UnboundMethod)
>>
> Except the two are really very different classes of things: are there 
> any reasonable circumstances in which you'd want to allow either a 
> Method or an UnboundMethod? In fact, this is actually an argument 
> against the current hierarchy, as there are times when the interpreter 
> allows either Proc or Method objects, but should explicitly _not_ 
> allow UnboundMethods.

I thought I'd used Methods and UnboundMethods before in a section of 
code, but after going to find it again, I remember now that I 
encountered the problem you suggest, and have since changed it to use 
#send with symbols instead of Method objects. I now understand (and 
agree) with your point about Method vs UnboundMethod.

But I still don't think #arity should be a mixin. =:)

--
Michael Granger <ged / FaerieMUD.org>
Rubymage/Believer/Architect
The FaerieMUD Consortium