Subject: Re: AOP without the buzzwords
Newsgroups: gmane.comp.lang.lightweight
Date: 2004-06-07 13:24:25 GMT (3 years, 49 weeks, 9 hours and 31 minutes ago)
At 1:45 PM -0500 6/5/04, Howard Stearns wrote:
>I have the same question, because I know MOP and CLOS and don't
>really know AOP. I'd like to offer a straw-man partial answer for
>comment:
>
>For whatever reason (e.g., a desire for extensibility in "open
>implementation" programming, or simply a desire to not have to
>practically repeat oneself), there are a number of specific things
>we'd like to be able to do. Two that I can think of are:
>
> 1) To an existing system, we'd like to be able to add a protocol
>for a new behavior -- e.g., something expressed by a new set of
>verbs, whether implemented as functions, methods, messages, or
>whatever it is that your language does. But we don't want to have
>to to break into the existing class definitions to add the new
>methods. And yet we still want the new system to function in all the
>old ways with the old existing classes.
>
> 2) To an existing system, we'd like to be able to add new kinds of
>objects that aren't necessarilly specializations of the existing
>ones. We want the old protocols (old verb behaviors) to continue
>working when handed thes new kinds of objects as argument, but the
>existing code might need additional blocks of code added to handle
>this. We don't want to break into the existing methods or functions
>to add new switch statements based on the types of the arguments.
>
>I don't suppose support for these two alone are sufficient, and I
>don't know enough about AOP or its community to know if they're even
>considered necessary. But I imagine that language mechanisms that
>help with these are candidates for being regarded as AOP-enabled.
>
>For example, once you have the ability to do both of these and
>actually start to create a system based on this ability, you quickly
>find that you want to not just supercede one piece of behavior with
>another, but to extend it. (e.g., to invoke all applicable behaviors
>and combine their results in some way.)
>
>Multimethods as in CLOS or Dylan count, but I imagine it's not
>enough to just have this ability -- you have to use it, and probably
>in a particular way. I don't have any answers on what that might be.
As far as I can tell, if you have the following, you
can pretty much do what AOP requires:
- CLOS- or Dylan-style generic function-based multi-methods
- reasonably capable macros, as in Lisp, Scheme, or Dylan
- function "advice", which exists in most Lisp implementations,
but nothing else AFAICT