From: Trans <transfire@...>
Date: 2005-10-20T00:46:58+09:00
Subject: Re: Cut-based AOP

Jeff Wood wrote:
> Although I see the power of the examples and the ideas, it seems like
> it's a bit watered down compared to AspectJ or other Aspect
> frameworks.

As the RCR points out, this is purposeful and with good reason. We've
designed a foundation. Ruby has plenty of capabilites for doing these
other "watered up" things. The problem with these other frameworks is
that you are always forced to do the "watered up" thing, but more often
teh usecases don't warrant it.

> Usually, the definition of cuts allow you to wrap many things at once...

You mean *cross-cut*. We draw a distinction. In fact, I'm not sure if I
have ever seen anyone else use the term "cut" withuout "cross". It is a
distinction that may be original.

> AspectJ ( for instance ) allows you to use wildcards in both the
> object type and the  method names that are getting wrapped.  It allows
> you to add general functionality ( like debugging logs or security
> control ) very easily to chunks ( of any size, even all ) of your
> application.

We've explored this extensively. Cutting based on method names is very
*bad*. And while wildcard cutting seems great, you'll find that adding
aspects to *all* or even *most* of your app is rearely desirable.
Typically, it is very specific classes and specific methods within them
that need advising. The exceptions are for meta-programming needs like
unit-testing and debugging. But as I say, these are exceptional. (It is
rather ironic perhaps, but many people do not even think of AOP as
being applicable to anything but these "meta" usecases b/c of the way
current AOP frameworks work!)

> I'd like to see something like that for Ruby, but I do think that your
> idea is a good start.
>
> maybe something that allows cut to take some wildcards
>
> Cut.new( "FileLogging" ) do
>
>   wrap_method( File, :any ) do |method, *args|
>     # do logging stuff
>     method.call( *args )
>     # do more logging stuff
>   end
>
> end

This can be done with the RCR as proposed, along the lines of:

  cut FileLogging < File

    redirect_advice instance_methods => :log

    def log( target )
      # do logging stuff
      target.super
      # do more logging stuff
    end

  end

> or instead of File ...simply
>
>   wrap_method( IO, :any ) ...
>     ...
>   end
>
> which would turn around and add this cut to any object of that type (
> or a derivative ) of IO

Your example would have to be expanded on, it's not explicit enough.
Nonetheleass you can do such things in similar fashion to the above
example.

> Anyways, just additional thoughts.  Shouldn't be too hard to implement
> as objects now within Ruby as it exists...

Right!

> The only trick is catching overrides and new types that are defined
> AFTER the cut has been added.

Indeed, that requires some extra code in a #method_added hook. And
certainly it would be possible to write some methods that did that
automatically too. Cuts can advise #method_added hook too ;)

I think the important thing to understand is how Cut is a foundation
for AOP. Going the direction of Aspect/J and the like, IMO, are like
building a house from the roof down.

T.