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

On Sat, 22 Oct 2005, Eric Mahurin wrote:

> --- Peter Vanbroekhoven <calamitates@gmail.com> wrote:
>
>>> The syntax is not consistent:
>>>
>>>        class B                meta-class of b
>>>        -------                ---------------
>>> reopen  class      B ... end   class <<b ... end
>>> cut     cut Bcut < B ... end   cut   <<b ... end
>>
>> Well, for the moment the patch does not allow this (I'm not
>> claiming the
>> patch is perfect, or even does all that we want it to do),
>> but the full
>> comparison would be this:
>>
>> open      class B < A ... end     class <<b ... end
>> cut       cut   B < A ... end     cut   <<b ... end
>>
>> reopen    class B     ... end     class <<b ... end
>> 'recut'   cut   B     ... end     cut   <<b ... end
>>
>> open'     class B     ... end
>> cut'      cut   B     ... end
>>
>> This seems consistent enough to me.
>>
>> What I've always found a pity though, is that the meta-class
>> declaratiopn
>> does not allow naming the meta-class, maybe like this:
>>
>>    class Meta_b << b ; end
>
> You are starting to touch on the inconsistency by asking for
> the meta_class to be named like other classes are.

No I'm not. My previous remarks have nothing to do with AOP. These were 
side remarks. I was just saying that it would be nice to be able to name 
it, not just within AOP, but in meta-programming in general. AOP involves 
a lot of meta-programming, so it was only natural that I mention this 
here. If it shows an inconsistency for AOP, it's there for subclassing 
too.

>                modifies
>                --------
> class A < B     A
> cut   A < B     A, B
> class <<b       b.meta_class
> cut   <<b       b.meta_class
> class A         A
> cut   A         A, B ??

One thing is that a cut indeed modifies B as well, while a subclass does 
not. So if you're looking for differences there, well, they're bound to be 
there because that's the idea.

cut <<b modifies the cut itself, as well as the meta_class it cuts, and 
cut A indeed also modifies the cut class (in this case B). This should 
complete your table above and makes it consistent again. That's if I 
understand it correctly.

> The meta_class vs. normal forms just don't seem consistent.

But what's not consistent. You give tables, there is something different 
(which is intentional, we wouldn't need cuts if they did the same as 
classes, now would we?), but what's your point?

> I have another idea that can be implemented in pure ruby using
> flgr's 'evil.rb'.  I'll send out another message about it.

Don't tell me it uses Object#become!

Peter