Could you elaborate a bit what you meant by "static language" versus "dynamic language"? I don't think I understand. Thanks.

I was searching for a more diplomatic term for the LFSP/LFM divide :-) Perhaps some examples will illustrate.

In an language with metaclasses you can isolate behaviour to a metaclass in a similar way to the way you move behaviour to an aspect. For example, in Python you could add behaviour to object initialisation by creating a custom __init__ method in a metaclass. See A Primer on Python Metaclass Programming for an examples.

In languages with eval() like functionality you can make runtime changes to your codebase. Perl developers regularly do code generation at compile time. In languages like Java this is impossible. Aspects give some of this power to Java.

In languages that support mixins and other forms of multiple implementation inheritance you can separate out some concerns into separate class-hierarchies.

If you have mixins, metaclasses, macros, runtime access to your language, etc. you find that you need aspects less. Many uses of aspects in languages like Java are to get around issues with Java's design (e.g. the use of AspectJ to create mixins).

This isn't to say that AOP is a useless or unoriginal concept. There is still the core difference from normal OO code in that an aspect imposes a behaviour on a class, rather than a class requesting behaviour from an aspect.

However, IMO, the arguments for AOP are less compelling when your language is more flexible.

Thanks for taking the time to clarify. Sometimes I'm just not sure if someone means "static" vs "dynamic" as defined by dragonchild, or uses it as "diplomatic" term.

I have nothing for or against AOP. Just found it an interesting item to explore and play with. It's more important to force someone to solve the problem right than to force someone to use a particular tool.

For example, in Python you could add behaviour to object initialisation by creating a custom __init__ method in a metaclass.

I'm curious - how do you see Perl or C++ or Java lacking this behavior? I know that my personal baseclass has the following lines in the new() call:

   my $init = $self->can('init');
   $init && $init->($self, @_);
[download]

That way, I can define a method init() in every class that derives from this baseclass (which is just a way of encapsulating getter/setter/mutator generation and enforcing attribute creation) and I seem to have the same behavior you're touting Python for ...?

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

I'm curious - how do you see Perl or C++ or Java lacking this behavior?

Because Perl, C++ and Java do not have metaclasses.

I know that my personal baseclass has the following lines in the new() call:

That's the difference. You have to add code to the new() call. In Python (or other languages with appropriate metaclass support) you don't have to change your baseclass's methods at all, you just say that your base class is implemented via a specific metaclass. The metaclass behaviour is completely separated from the object classes implementation.

For example, imagine that the behaviour we wanted to add to object initialisation was logging. Now imagine that our logging requirements change and we need to log all access to object mutators in addition to object initialisation. In a language without metaclasses we would have to add a method call to every mutator. With a metaclass you just have to change the way that mutators are implemented to include a call to the logging routines.

It can also refer to the fact that Perl is (somewhat) introspective, like LISP, while C/C++ is not. You can dynamically generate executable code in Perl, because it's interpreted. You cannot do that in C++. (Well, that's not entirely true, but it's close enough for this discussion.)

Hope that helps!

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.