Curious about AOP in Ruby, I've downloaded the Cut patch for 1.8.3,
installed gperf, and am trying to understand a few things.  But - the Cut
RCR thread appears to have died.  From comments about the RCR, the voting
appears to be positive - something like 10 votes for and 2 against.  Not
being familiar with the RCR process - is Cut going to see the light of day?
Has another AOP RCR or library been proposed which has captured mind share
bringing a premature end to Cut?  Are the majority of Ruby developers
seeking to use AOP satisfied with aspectr?

On 10/24/05, Trans <transf...@gmail.com> wrote:

Others may have other opinions, but I'm not sure that it's necessary.

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

   1 class Module
   2   def attr_transformer(*attrs, &block)
   3     attrs.each do |attr|
   4       define_method("#{attr}=") do |value|
   5         instance_variable_set("@#{attr}", block.call(value))
   6       end
   7     end
   8   end
   9
  10   def attr_validator(*attrs, &block)
  11     attrs.each do |attr|
  12       define_method("#{attr}=") do |value|
  13         if block.call(value)
  14           instance_variable_set("@#{attr}", value)
  15         else
  16           raise ArgumentError, "invalid value"
  17         end
  18       end
  19     end
  20   end
  21 end

How would one use #attr_transformer and #attr_validator together?
Ideally, you could do this:

   class Module
     def attr_transformer(*attrs, &block)
       attrs.each do |attr|
         define_aspect("#{attr}=") do |value|
           # call the previously defined method, or
           # super, if none exist.
           previous(value)
         end
       end
     end

     def attr_validator(*attrs, &block)
       attrs.each do |attr|
         define_aspect("#{attr}=") do |value|
           if block.call(value)
             previous(value)
           else
             raise ArgumentError, "invalid value"
           end
         end
       end
     end
   end

   class Foo
     attr_accessor(:bar, :baz)
     attr_transformer(:bar){|value| value ** 2}
     attr_validator(:bar){|value| value > 0 and value < 10}
   end

   foo = Foo.new
   foo.bar = 3

The following would then happen:

   1.  The aspect defined by #attr_validator will be called.
   2.  The aspect defined by #attr_transformer will be called
   3.  The method defined by #attr_accessor will be called

Of course, one could just make do with a `previous' keyword in the
normal method definitions.

Cheers,
Daniel

Daniel

[...]

  class Foo
    attr_accessor :bar
    remove_method :bar= ;
    def bar=(val) #:nodoc:
      raise ArgumentError unless (value > 0 and value < 10)
      @bar = val ** 2
    end
  end

Or I'd look at using Ara's "traits" library (bad name, interesting
library that so far I haven't needed).

Your example is a particularly bad one because it's the space that
*should* be handled by methods. But (IMO) you shouldn't want to build
your code in the way that you have just done; it divides the code very
badly.

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

Daniel

http://mail.python.org/pipermail/python-list/2003-November/193337.html

T.

I'm happy with the pre and post hooks planned for 2.0.

I'm looking for ways to put *harder* shells around pieces of well-tested and
well-designed functionality, not for ways to slice them open even more. The
article you cite makes a big deal out of "loose-coupling" (the buzzword of
the decade) as a goal for AOP. I'd rather accomplish that with asynchronous
messaging.

Austin is right, we don't need AOP.

  require 'cuts'

if one so chooses.

Implementation unfortuately is a bit tricky, and a pure Ruby
implementation is impossible, but it's not that far off, and I'm sure
if Matz and Peter Vanbroekhoven got together they could iron out a way
for it to be reasonably implemented as an optional .so. Any way you
slice it, Ruby can only benefit from such analystic work.

T.

I *still* don't see the value in it. Instead, I see significant
problems with the maintainability of such code.

IMO, AOP exists primarily because of the limitations of Java.

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

transfire - from your response, it would seem that AOP for ruby is alive and
kicking - is work moving forward to include Cut within Ruby proper?  If so,
would you expect it in a 1.8.x release or later?

On 6/14/06, transf...@gmail.com <transf...@gmail.com> wrote:

Yes, I'm one of the folks who is "strongly opposed" to the cut-based
AOP RCR that you've written. I think it's unnecessarily complex and
there are better and more-established ways of offering such
extensibility.

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

2. Matz is the only one who would be able to indicate such a change as
"alive"; not trans, not me, not anyone else.

3. Even if it is accepted, it will not see the light of day
(officially) until Ruby 2.0 or later. It will never be in a 1.8.x
release because it's a major change.

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

Austin,

Looking around, you have hundreds of posts, and you're involved as a mentor
in Google Summer of Code " Automated Wrapper Generation for Information
Extraction" arena.  I take it you have the experience to back up what you're
saying.

Can you provide references to better and more-established ways of offering
such
extensibility?  I looked briefly at traits which you'd alluded to earlier,
but it requires changes to the core code for trait/hook insertion.  I'm
interested to read about other mechanisms which are more maintainable and
extensible than AOP in Ruby if you could please share them.

I ask not to inflame, but to draw out an open discourse around this matter.

On 6/14/06, Austin Ziegler <halosta...@gmail.com> wrote:

Cool, I'm willing to be proved wrong. Hack it into Ruby so I can try it
(patch the language if you have to- Lord knows I've done that enough times),
write up the use cases with working examples in non-trivial programs, and
show how it's better than competing approaches.

It seems to me that Ruby has enough extensibility built in today, so that
with an IoC/DI approach you could do everything you can with AOP. But here
(and elsewhere) AOP is being presented as a new style of programming with
unique value, and that is far from convincing at the moment. I can see the
value of adding crosscuts (and DI) for system management and debugging
support, but not for extending application functionality. Until proven
otherwise, I'm going with my intuition that this is an excellent way to make
complex systems even more complex, fragile, and hard to manage.

  class Foo
    def bar
      pre_baz if respond_to? :pre_baz
      baz
      post_baz if respond_to? :post_baz
    end
  end

Matz will be providing (somewhat) cleaner ways to do this, but that's
the essential nature of the beast. It's a form of plugin-style
programming and that's well understood, while AOP is a poorly defined
and easily misunderstood beast.

Similarly, mixins provide the main capability that Ruby needs -- but the
original programmer has to write the code to be able to deal with this
properly. And if they don't, you can always inherit or compose.

I think that it's important to note that *even now* (five years on from
the PARC research) you can't find many clearly-written, concise
explanations of AOP and why you'd want it. It's all buzzwords.

AOP may be valuable. But I have yet to see anything that convinces me
that it's worth all the bother. It's sort of like Inversion of Control.
Interesting, but not relevant to most (98%+) needs.

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

# Pseudocode
class String
    def pre
       self.replace(MultiToWide(self)) if TextIsUnicode(self)
    end
end

Maybe smarter minds than I could take this idea further.

Regards,

Dan

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/29...

All you need is Object#become from evil.rb.  You could write a few
wrappers to make this look prettier.

I think if some AOP thing is added to ruby, it should be something
very simple that could be extended to some elaborate AOP framework
(rather than starting with an elaborate framework as trans suggested -
that includes new keywords!).  Here are some of the simple things that
could be used as a a basis for AOP:

- pre and post method hooks (what matz is planning)

- Object#become/Class#replace.  Can be implemented now in pure ruby (evil.rb)

- something like Module#include except "super" (or something else) in
the included methods refers to the previous method definition.

Eric

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.

T.

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 * halosta...@gmail.com * http://www.halostatue.ca/
               * aus...@halostatue.ca * http://www.halostatue.ca/feed/
               * aus...@zieglers.ca

Thanks Eric.  As I see evil.rb, and Object#become - we're basically looking
at object inheritance, which may get the job done in some cases, but
violates the separation which AOP is attempting to provide/enforce.  I'm new
to AOP as well as Ruby, but strictly from an OOP persepective, I don't want
to assume the responsibility for all methods of the parent for the purpose
at hand - behavior monitoring / modification of 1-n methods of the class.

On 6/14/06, Eric Mahurin <eric.mahu...@gmail.com> wrote:

Folks,

Aspects are bad (but perhaps a necessary evil in Java) and Ruby doesn't need
them.

Aspects provide a theoretically interesting facility to insert code around
methods or around calls to methods.  They provide meta-programming
facilities to Java, a language that was designed for type-safety and without
meta-programming in mind.

In my experience, Aspects have been used by Java developers during
development/debugging to "figure out what's going on" with calls to
particular methods.  Aspects provide a nice set of runtime debugging tools
that allow the developer to trap and trace particular calls and/or call
patterns in a way that simply setting a breakpoint cannot do.  Aspects work
pretty well for this application.

Aspects are also used to add "features" to existing classes.  The
prototypical use in my experience is to add transactions into a series of
JDBC (database) calls that didn't have transactions before.  To the extend
that the source code for the original libraries is unavailable or infeasible
to change, Aspects work okay to patch code.

However, Java's execution model and gestault revolve around execution
predictability.  Once I write, test, and deploy a class, the execution of
the class and its side effects are knowable and verifiable.  This is good
from a security and testing standpoint.  This is perhaps Java's greatest
strength for large-scale projects.  Aspects destroy this model and
fundimentally weaken Java.  Depending on the Aspects in use during
development, during testing, and during deployment, execution of well tested
code can change and not work correctly.  The model for describing Aspects is
broken and can lead to over-broad application of an Aspect such that code is
unintentionally broken because of the way an Aspect is described.

Ruby doesn't need Aspects.  Ruby's open class structure means that any code
can perform necessary surgery on an existing class in a well defined, well
understood fashion.  Ruby's meta-programming facilities (alias_method, open
classes, etc.) allow a Ruby developer to wrap methods from other classes,
redirect execution, etc. in a predictable, programmatic fashion.  Ruby has
the meta-programming facilities to provide method wrapping, logging,
performance monitoring, etc.

My 2 cents.

Thanks,

David

On 6/14/06, Austin Ziegler <halosta...@gmail.com> wrote:

While everyone's busy bashing AOP, other people are trying to see what
*orthoginal design* can do. It would be nice if we could use Ruby to do
the same and with a solid foundation like cuts (which again would be an
optional library).

But to play along a bit you might be interested to know that the whole
reason I got into AOP is because I started doing AOP before I even knew
what is was or that the concepts were already out there. Perhaps you
recall GUtopIa? Well, that was a GUI framework I wanted to build for
Ruby. The way I wanted it to work required method-wrapping entire
classes! After some nasty meta-coding that would make most people's
eyes pop out, I started to thinking I needed some kind framework, and
lo, I discovered the concepts were already out there in AOP. I put
GUtopIa on the back burner and decided to pursue AOP for Ruby with the
ultimate hope of returning to GUtopIa when good AOP support was in
hand. That's how the Cut-based AOP RCR got developed. It wasn't just an
abstraction pulled out of the thin air. Thankfully I met Peter
Vanbroekhoven, an monumentally capable coder, and together we spent
nearly two years studying AOP concepts and hammering out possibilites.
What we ended up with, while perhaps not perfect (is anything ever
perfect?) is a clean foundational system that supports all the
requirements of AOP without forcing anyone into a specialized
high-level way of doing things --you are free to abtract to top of it
as *you* see fit.

Seems like a good deal to me.

T.

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