From: Jeff Wood <jeff.darklight@...>
Date: 2005-10-20T00:54:08+09:00
Subject: Re: Cut-based AOP

Thank you for the clarification.

j.

On 10/19/05, Trans <transfire@gmail.com> wrote:
> 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.
>
>
>


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood