From: Trans <transfire@...>
Date: 2005-10-21T00:42:00+09:00
Subject: Re: [RCR] Cut-based AOP

Hi Matz,

Yukihiro Matsumoto wrote:

> I understand the basic idea.  How about introducing a new method
> e.g. "preclude" that works to intercept the methods in the target
> class/module, instead of cut.  It would be a counterpart of "include"
> for mix-in.

Yes, this is in the RCR:

Additionally, Cuts exist in proxy form to allow modules to be
"premixed". This is analogous to proxy classes which allow modules to
mixin to the class hierarchy. So too does a proxy-cut include a module,
albeit preclusive rather the inclusive in its effect. We offer the
module command #preclude to serve as designator of this purpose.

  module A
    def m ; "<#{super}>" ; end
  end
  Class T
    preclude A
    def m ; "okay" ; end
  end
  T.new.m  #=> "<okay>"


I am amazed how quickly you've latched onto the most probable usage. I
have known for sometime that "preclude" would be the most utilized part
of this. But I have avoided stressing it becuase it is important that
it too be supported by good foundation, which is the Cut. Just as there
is a *proxy-class* to *mixin* modules, there'd be a *proxy-cut* to
*premix* them. Although precluding modules will certainly be utilized
most, I do not see any benefit in hiding the underlying class which
facilitates them from the programmer.

OTOH, perhaps you have a different idea for the implementation of
precluded modules; one that avoids any sort of cut/proxy-cut class
altogether. If so, I must tell you, I am cautious of such an approach
because it implies "adding-on" rather than "integrating". IMHO,
integrating this "atomic-aspect" formally into the OO class heirarchy
would be of greater benefit to Ruby, and potentially influential on OOP
in general. From a comparitive perspective, it is the difference
between Ruby simply having an extra feature and Ruby having a new and
original object-oriented feature.

T.