On Wed, 19 Oct 2005, Christophe Grandsire wrote:

> I've just voted "strongly advocate" for it! After reading about AspectJ, I had
> found that although aspects where interesting, they looked like they broke OOP
> rather than enhanced it. This proposal, on the other hand, is strongly based on
> OOP and really enhances it, and also makes AOP much easier to understand than
> the traditional approach and its swarm of buzzwords. And it is nicely
> unintrusive, ensuring that if one doesn't want to bother about AOP one doesn't
> have to.

Great! One down, many more to go ;-)

> I just have a few questions, which I hope aren't too dumb ( ;) ). I couldn't
> find anything in the RCR about those questions (although I may have missed it):
> - will one be able to subclass (are rather "subcut", one would say) cuts?

Cuts are not supposed to be subclassed (they can't be instantiated, so 
what is the point?) We're not sure if we want to allow adding cuts to 
cuts. I think the current implementation allows that, but I'm not sure, 
it's been a while.

If you want to reuse the functionality of a cut somewhere else, you should 
put it in a module and reuse it like that. In a way, allowing a cut to 
apply to multiple classes or modules is akin to multiple-inheritance, and 
we want to avoid that.

> - will cuts be as open as classes? (since they *are* classes, I'd expect so, but
> I just want confirmation)

Yes, they will be open wide.

> - how do cuts work with each other when you add more than one cut to the same
> class?

They stack on top of each other, the last one added being on top:

   class A
     def m ; '1' ; end
   end

   cut B < A
     def m ; '[' + super + ']' ; end
   end

   cut C < A
     def m ; '{' + super + '}' ; end
   end

   p A.new.m # => "{[1]}"

> - will the subclass of a class also inherit its superclass's cuts? This is a
> tricky point I think, as one might expect that the functionality provided by
> cuts should be available to subclasses, but the implementation (which is
> basically like transparent subclasses) may forbid it. If they don't inherit
> cuts, this could lead to surprises, with a not overriden method behaving
> suddenly differently in the superclass and in the subclass. And what should one
> expect of the behaviour of "super"?

Yes, subclasses inherit the cuts. This means that in the class hierarchy, 
the cuts are in between the class and the superclass. To show this, some 
example code:

   class A
     def m ; '1' ; end
   end

   class B < A
     def m ; '{' + super + '}' ; end
   end

   cut C < A
     def m ; '[' + super + ']' ; end
   end

   p A.new.m # => "[1]"
   p B.new.m # => "{[1]}"

So the methods of a class are seen the same from the outside and from the 
subclasses.

Note: if you use the patch, the keyword 'cut' is named '__cut__'. This is 
because the Tk library uses 'cut' as a method name and it fails the tests 
otherwise.

> All in all, I find it one of the best RCR I've ever read! Keep up the 
> good work!

Thanks!

Peter