For what it's worth (not much), I'll share my perspective on this.  At
work I'm an 'enterprise' Java developer.  Did C++ / Tuxedo before that.
At home I use Ruby a lot.  At one point I was pretty keen on AOP and
even developed a little framework for PicoContainer that integrated Pico
with DynaAop and Groovy.  Committed it, never actually used it myself.
My work project switched from Pico to the Spring framework.  

We use Spring for dependency injection and AOP.  We use Spring AOP for
one thing.  No, not logging - we use it for transactions.  In Java AOP
is nice for that.  But even there, the whole Spring thing is
complicated.  When I try to explain that Spring is complicated to folks
at work, people look at me like I'm a little dim-witted.  Poor Steve, if
he can't handle Spring, how would he ever have coped back in the day,
when we did EJB?  Now that was configuration for real men.

But in the Ruby (and Rails) world, things are a *lot* more
straightforward.  I don't miss my DI or AOP config files at all.  99% of
the time DI is used to make it easier to mock things out for testing.
But in Ruby classes are modifiable objects.  So you can just plug a
different implementation of the new factory method, or plug in new
defitions of the problematic methods, or subclass the problem thing in
the test, or what have you.  I'm probably missing some options.  But
I've never found hard to mock stuff out for testing.

I'm not sure we would need AOP for transactions as much in Java if there
was a nicer syntax for anonymous classes.  Passing a block to File.open
or Transaction.execute in Ruby is so straightforward.  As for as
introduction goes, well I have felt the need in Java on occasion to
mixin in a class.  Not so strong a need that I reached for AOP to do it,
but it would be nice.  Again though, Ruby has mixins and open classes,
so no real need.  It would be nice to have some sort of namespace
selector mechanism so that you could apply introductions just to certain
scopes.  Beyond that though, I'm good.

A few times I have aliased a method in Ruby and had the new method
definition call the old.  Simple, but it can feel a bit hackery.  I like
the idea of pre/post and around advice constructs.  I'm familiar with
that from Lisp, and it didn't seem to destroy the language or anything.

Although I might word it a bit more softly, I tend to agree with Austin
-- Ruby doesn't need AOP, at least not too much beyond what it already
has.  The only minor things that I might like added are already being
discussed for Ruby 2.  I wouldn't want anything too fancy added to the
language itself or the standard library.  Simple is good.

Steve

-----Original Message-----
From: Austin Ziegler [mailto:halostatue / gmail.com] 
Sent: Wednesday, June 14, 2006 11:55 AM
To: ruby-talk ML
Subject: Re: Cut-based AOP

On 6/14/06, transfire / gmail.com <transfire / gmail.com> wrote:
> You know, it's easy to spout YAGNI and AYRHTDI (All Your Really Have 
> To Do Is) and such. It's whole nother story when you actaully WORK on
it.
> Try spending two years studying AOP and how it could work in Ruby and 
> then get back to me. There's more to it than you understand.

If it takes two years of studying to "get" AOP, then I definitely *do
not* need it. IOC is easier to understand than that, and I think that it
has more value in Ruby than what I've understood of AOP.

AOP *may* be a revolution in programming, but *no one* has been able to
explain its real and immediate value to me in any way. I didn't do OOP
for years, but I *got* it very quickly when I was taught it.

Here's the challenge. Let's accept, for the moment, that your RCR
represents the Right Way to do AOP in Ruby. Now, convince me that we
need your RCR. Sell me on AOP. Tell me what the benefits are -- *show*
me the benefits in code. Show me that my code will be shorter, easier to
understand, cleaner, more extensible, more secure, *whatever* with AOP.
Right now, if I want to give someone hooks into my code, I make explicit
plugin points. If I don't and someone wants to modify either the input
or output of my method, then they can either wrap me through inheritance
or composition. I really do *not* get the value that AOP gives me, and
the example given in the Python mailing list link you gave me is clever,
but I can't see *value* there.

We've had a discussion recently. *Convince* me that AOP will make a Ruby
developer's life significantly better than what I have described
("plugin points", inheritance/composition wrapping) as well-understood
and I'll support you. My problem isn't with your RCR; my problem is with
AOP. Right now, it's just a buzzword with little value. If it has value,
I am convinced that you can change my opinion.

-austin
--
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca