From: Peter Vanbroekhoven <calamitates@...>
Date: 2005-10-20T01:15:11+09:00
Subject: Re: [RCR] Cut-based AOP

On Wed, 19 Oct 2005, Dave Burt wrote:

> 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".)

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.

>> 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?

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.

Peter