Peter Vanbroekhoven:
> Ah, I see. But you asked "shouldn't cut be a module". There's no "a" 
> before the "cut", which causes the ambiguity. I just asked to make sure I 
> wasn't misinterpreting. I do that when there are these tiny ambiguities in 
> a sentence.

Ah, yes. I'm not doing too well with accuracy in this thread, am I?

>> I don't see the balance falling the same way -- I see Cut much happier as 
>> a
>> peer to Class than a subclass of it.
>> - My main reason is that a subclass of Class should be instantiable; 
>> that's
>> the primary difference between Class and Module.
>> - That singleton classes aren't instantiable is an interesting point, but
>> those are kind of obscure, whereas a cut is not, with an added keyword 
>> and
>> all.
>> - Cut#superclass and Class#superclass are different, as it's a different
>> kind of relationship.
>> - include and extend only accept objects whose class is Module, so this 
>> is a
>> non-issue
>>
>> Can you un-settle on it being a class?
>
> Sure. We've never managed a final decision on this, and because 
> implementation-wise both are possible, we settled on one of them to 
> prevent us from getting stuck arguing over a detail that is easy enough to 
> change. Problem is that most arguments for or against making cuts modules 
> are not conclusive or at least partly subjective. You make a pretty good 
> case though.

Thanks. I do feel pretty strongly about my first point (classes are 
instantiable) and I think it really comes down to that on the Module side 
versus cuts being part of the class inheritance heirarchy on the other. And 
the nature of cut inheritance does separate it from the class heirarchy.

Cheers,
Dave