From: transfire@...
Date: 2006-06-15T06:48:32+09:00
Subject: Re: Cut-based AOP


Austin Ziegler wrote:

> Except that I have no more understanding of the practical benefit of AOP
> than I did before your post.
>
> That's what I want, Trans. Help me understand. I'm *not* trying to be
> down on this, I'm just trying to cut through the buzzwords that most AOP
> proponents use. At this point, I don't see any benefit that can't be
> replicated through far better-understood mechanisms that would suggest
> such a major language change (even if access is limited through loading
> a support library as well).

Okay, then. I will try to explain my view of why AOP may well be a very
valuable and powerful paradigm. For now, toss out all the specialized
terminology like join-point and crosscut, etc. And forget all the hype.
Lets focus on the very heart of the matter with my original conception
of it.

Here is how I saw it when I was working on GUtopIa: I imagned a
programmer with some core application, doesn't really matter what kind,
and wanting to add a GUI interface to it. Now, I didn't want the
programmer of that applicaiton to have to change the code in anyway
whatesoever. I wanted the whole of the GUI to operate "in addtion to"
as a separate layer to the core app.. So I imagined the application
like a sheet of "electric" paper, a 2D landscape where all the code and
it's bustling activity could be seen in real time --all the objects,
all the classes and modules, all the various states of system, there to
be gleened. So I imagined that. Then I imagined another system reaching
down and tapping into specific places in that landscape, extrating out
the data relavent to its job --in this case displaying that information
in human readable form and sending information back to trigger off new
events in the 2D world. Thats how I first concieved ti and as it turns
out, in this imageary we have the basis of AOP. The sheet of electric
paper is the OOP application and the related GUI code is an "aspect"
acting "orthogonally" to it.

Now you can of course achieve much of the same _results_ using pure OOP
techinques. But it will require, in some fashion or another, changes to
the orginal piece of paper, using constructs like adaptors and the
observable pattern. In so far as one manages to move away from having
to make these kind of changes, using Ruby's powerful meta-programming
techinques for instance, I charge that they have already begun to use
AOP techniques. Indeed the terms "meta" and "orthogonal" are really
synonyms here. While Ruby's meta-programming features are great and can
be used to do AOP-esque coding, they are nonetheless highly specialized
to Ruby, lack for certain capabilites --or at least make them more
difficult to achieve, and can actually inhibit code reuse. Whereas the
implementation of a fully formalized concept of AOP would do just the
opposite.

I'm not going to fool myself into thinking this is remotely enough to
convince you. But I hope that it will at least give you some
appreciation for why I think AOP could well have great potential, why
I've worked so much on it, and why I think it can only be beneficial to
have a Ruby library available for doing it well.

T.

Short answer? It's all about the S.O.C. man ;)