From: Dave Burt <dave@...>
Date: 2005-10-22T16:17:01+09:00
Subject: Re: Cut-based AOP

Trans:
> On the other hand cuts are in essence classes --transparent
> *subclasses* to be exact. While you do not instantiate them directly,
> they get instantiated as part of the class they cut.

I've just finished catching up on this thread (phew!) and you do make a good 
point here. I still think, though, that a Cut is fully a Module, but only 
partly a Class; it has a superclass but cannot be instantiated. I still 
think that means Cut < Module and not Cut < Class.

> I think the real incongruency comes more from the fact that Class
> itself is a subclass of Module. It works okay, but conceptualy it is
> odd. And on occasion you have undef a method in Class that's been
> defined in Module. I think Matz even metions something liek this in his
> recent presentation. It think a better solution would come from having
> a "ClassKernel" module which is included in Module and Class, so they
> can stand on their own.

I'm don't think it's really an inconsistency in the current system, it just 
makes Cut's place a little unclear.

> Finally, I think cuts are simliar to singleton_classes in that
> instantiating them is restricted.
> ...
> But I don't think there's any techincal reason they could not be. It's
> purposefully disallowed, I guess for conceptual reasons:

The comparison is interesting, and adds weight to your preference for class 
over module, but it is a bit arbitrary in itself, and it doesn't mean 
_another_ kind of class with no #new is OK.

>    if (FL_TEST(super, FL_SINGLETON)) {
> rb_raise(rb_eTypeError, "can't make subclass of virtual class");
> ...
> Hey, this still says "virtual class"; _why doesn't his say eigenclass!?
> ;)

Another RCR? =)

Cheers,
Dave