Marcel,

Thanks for your interesting reply.

> too far beyond the state of the art, ... to be able .. to take ... management
with them 

I agree completely with the disappointment of AspectJ; it is quite likely a
result of short-term corporate thinking. The same kind of thing seems to
have hit the SOP team, at least when judging from the C++ hack--uh,
'extensions' I should say--they've been doing lately, not making justice to
the SOP concept, in my opinion. I'd have though it would be impossible to
add anything at all to C++, though.

However, my initial reaction to the earlliest AOP papers was, great, but
this can't require all-new languages--and if it does, it won't become
practical. After all, since in theory any language with full Turing-macine
capacity can do "anything", why would we need not just one new aspect
language, but one language *per aspect domain*?!! My intuition was that we
didn't need all that, but I was not yet certain. So what was "the thing",
the essence, of AOP; what was truly new? I think Czarnecki was just helpful
in putting it all in a context and into perspective; I also happened to read
Gilad Bracha's work on mixins around the same time, and these things taken
together made the coin drop.

I realized not long ago that the new thing was that the principles for
weaving parts (ie. aspects) into a whole are made *completely flexible*.
Single inheritance, MI, mixins, method combination, etc. all combine parts
(code, data) into a whole along various principles/rules--in this list, from
simple to more complex. Maximal power in specifying these rules, of course,
corresponds to full algorithms (etc.). In other words, that you can use the
full range of the language for specifying how different parts (aspects)
should be combined--state and process. In my view this is what aspect
weaving amounts to, and this full combination/weaving generality is what's
new about AOP. That also explains why I see AOP as the latest step in the
inheritance--MI--etc. line; as progressing toward more powerful and flexible
combination facilities.

(And you don't need *any* new language--as long as you have a reflective
language already--since your combination "programs" need to be able to
manipulate other programs and structures. It suprises me that the AOP team
didn't see this, since they are Lisp and reflection people already.)

Now, I'd very much like anyone to "falsify" my attempt to make sense of what
the essence of AOP amounts to, by showing something that I've missed. Don't
hesitate! Criticism helps in articulating your ideas, I think. (As
cybernetics states, negative feedback isn't bad feedback.)

Now "all" one would need is good programming support for specifying such
combination/weaving. (No, I'm not switching to Lisp, but I'm considering
using Prolog, the one in Squeak that is.) I'm experimenting with a pattern
matching format for specifying how aspects are combined; I believe in it a
lot, but Squeak's present MOP is not exactly made to be extensible, so
that's slowing me down. The toughest part is actually the browsers and other
tools, which are hardwired for ordinary Smalltalk, and so quite hard to
adapt to a new aspect organization format. They don't ask the class whether
it's okay to delete it (to check for dependencies etc.)--but hardcode it in
themselves, for instance. This is similar to the weaknesses of the MOP, by
the way.

This reply became rather long; I find it helps me to articulate my thinking
to someone else, though, so I don't mind. If you have any good references,
eg. to GenVoca, Join-Point theory or anything else you mentioned, I'd like
to have them, esp. if they are net-accessible (but not necessarily). Also,
which are the newer papers from the AOP group you are thinking of?

I hope to release my weaver to the list down the road; it comes down to how
nice people want it to be before they look at it. Esp. the browser stuff is
too big a chunk for myself to ever complete.

Henrik