I think it's worth emphasizing that AOP came out of the experiences of
experts in metaprogramming (e.g., Gregor was an author of "The Art of the
Metaobject Protocol" back in 1991). Its goal is to provide direct semantics
for modularizing crosscutting concerns, which turned out to be the most
important use of metaprogramming. Gregor wrote a great summary of this topic
in http://www.sdmagazine.com/documents/s=8993/sdm0411f/
The big benefits I see in a direct semantics over metaprogramming are
clarity and integration. Even with the explicit semantics and consequent
ability to provide tools support, the biggest objection I hear to AOP is
"how do I know what the code will do?" With metaprogramming, it's a
tremendous challenge to provide useful tools. While Ruby tools support isn't
mature, it is fast emerging, so even if your preferred environment for
coding Ruby today is emacs, in 3 years it could well be something like
Komodo with Eclipse sophistication.
In terms of integration, I contend that when you combine metaprogramming
implementations of crosscutting concerns, it becomes messy & very hard,
since there are so few rules of engagement, whereas AOP provides a lot more
infrastructure for this kind of integration. It may require some thinking,
but again direct semantics helps a lot.
I think the reason that so few dynamic language users are demanding AOP has
more to do with the scale of engineering projects on which they have been
applied. AOP becomes more valuable on larger scaled projects, as the lack of
modularity really hurts. At least until now static languages have dominated
in medium to large scale project use. But interestingly, the POJO movement
in Java has resulted in much more dynamic Java code (where reflection is
used to invoke arbitrary methods at runtime), yet frameworks like Spring
that are leading this effort have embraced AOP.
Indeed, why do you need OO if you have metaprogramming? Why not just
redefine methods and have the full power of defining your own favorite
version of inheritance for any class. Perhaps for the Ruby affectionatos
this could be phrased "duck calling" - just don't do it near our esteemed
Vice President!
Cheers,
Ron
_____
From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On Behalf
Of Ramnivas Laddad
Sent: Thursday, February 16, 2006 6:58 AM
To: Rick Bradley
Cc: discuss at aosd.net
Subject: Re: [aosd-discuss] AOP myths and realities article published
Rick,
Thanks. You make many good points.
I have started to hear more about AOP's need (or lack thereof) in the
dynamic languages arena. The most common opinion I hear matches that of
yours. It also seems that metaprogramming is proposed as the way to deal
with crosscutting concerns in dynamic languages, particularly Ruby.
I think the need for AOP will be felt when Ruby and other modern dynamic
languages have a more widespread adoption. At the risk of
overgeneralization, early adopters of any new methodology or language tend
to have a better understanding and ability to use complex features. At
today's adoption level, most Ruby programmers don't mind using advanced
metaprogramming features to deal with crosscutting concerns. This may be a
reason why the need for AOP isn't felt as strongly in Ruby.
Dynamic languages will need AOP just as well as statically typed languages.
While metaprogramming may get the job done, it may be too powerful for many.
Further it addresses crosscutting concerns in an indirect way (redefining
methods instead of advising them). At some point, realization for a more
direct expression of crosscutting features, and therefore support for AOP
(which may use metaprogramming as an underlying implementation technique)
will be felt. Statically typed languages met AOP on the way up to
metaprogramming, whereas dynamic languages may meet AOP on the way down from
metaprogramming.
It may also happen that AOP will be more successful in dynamic languages due
to, if nothing else, willingness of programmers to try out more out-of-box
ideas. Of course, it may happen that AOP will always seen as diluted form of
metaprogramming and thought leaders (who understand it well) may not promote
the AOP route. How this folds out will be interesting to watch.
BTW, here is a proposal to add AOP in Ruby:
http://www.rubygarden.org/ruby?AspectOrientedRuby
-Ramnivas
Rick Bradley wrote:
* Ramnivas Laddad (ramnivas at aspectivity.com) [060215 12:39]:
IBM developerWorks has published my AOP myths and realities article
(http://www.ibm.com/developerworks/java/library/j-aopwork15).
Ramnivas,
Congratulations! I enjoyed your article -- it was well written and
covers the waterfront well.
I've lurked for a long time on the aosd-discuss list because I find AOP
relatively fascinating, but I'll have to say I've found little occasion
to use AOP per se -- mostly because (at least my perception) I've found
little occasion to use Java in the past few years.
For a while I thought that this was due to the relative availability of
AOP tools for Java as opposed to elsewhere. These days I'm not so sure.
Programming a lot in dynamic and loosely/weakly typed [0] languages,
especially most recently Ruby, I first noticed that I relatively had
call for AOP constructs. After a while, though, I realized I was using
very AOPish constructs but they simply seemed like natural idioms in
dynamic languages. They didn't require a new formalism or terminology.
I began to wonder if I'd simply picked up enough AOP by osmosis and was
applying the principles. Possibly, but I've since noticed developers
who exhibit no recognition of "AOP" solving problems similarly in
dynamic languages.
I began to look back at AOP, and especially AOP in Java, and I began to
wonder if the in-depth study of AOP in Java wasn't perhaps due to
problems with Java itself, for which AOP becomes a necessary tool, the
burden of implementation of which in Java makes it ripe for study? [1]
Do you hear much of this sort of talk about AOP? Is this another myth
for the list of myths?
[0] Whatever one wants to call them, I don't want to split hairs at all
about what kind of typing whichever language has -- that's a waste
of time.
[1] Watching the talk about the Singleton design pattern I catch a lot
of similarities. When Java developers talk about Singleton they
find plenty of reasons why Singleton is "bad" or "evil". Looking at
Singleton from outside Java, Singleton seems perfectly reasonable
and useful -- it's simply the common *Java* implementation which has
gone astray.
Best,
Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060217/f18ff23e/attachment.htm