Peter Vanbroekhoven:
> First things first: when you talk about cut, is that Cut, or an instance 
> of Cut?

Yes. We're talking about the Cut in the inheritance heirarchy.

(I don't see the ambiguity; I'd read "a cut is a module" as "an instance of 
Cut is also an instance of Module", which implies "Cut < Module".)

> If it's the latter, then the answer is that we had long discussions about 
> whether Cut should be a subclass of Class or of Module. There are some 
> features that make it class, and some features that make it a module:
>
> * a module because:
>   - Not instantiable (though singleton classes aren't instatiable either)
> * a class because
>   - Not includable (though neither is Class which is a subclass of Module
>     too)
>   - It has a superclass, namely the class it cuts
>
> So you see, there are arguments for both, and in the end we settled on it 
> being a class.

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?

Cheers,
Dave